Commons:Village pump/Archive/2014/10

Toollabs facilitating MP4

I discovered today that someone has build a tool on wmf labs, that converts MP4 videos on the tool labs hardware, before uploading it to Commons. This seems to fly in the face of what was the output of Commons:Requests_for_comment/MP4_Video, which specifically said that we wanted NO mp4, not even through a converter ingress pipeline. In my opinion, we cannot just put a tool on labs afterwards, that is doing the exact same thing on WMF owned hardware and then say: "ah, but now it's cool"... I would like to hear more opinions.
P.S. I'm sorry User:Prolineserver, I think it is a great tool, but I just can't agree with it's existence on WMF hardware, in the face of that community consultation. —TheDJ (talk • contribs) 13:39, 7 September 2014 (UTC)

So, if the tool converts everything but mp4 on labs its ok? If the tool runs with the same functionality on a non-WMF server its ok too? Btw.: The conversion tool is much older than the rfc, and was previously running on tools.wikimedia.se and the toolserver. Since the beginning of the year it just moved to tools and got more user friendly with the OAuth and jQuery upload. --Prolineserver (talk) 15:49, 7 September 2014 (UTC)

Yes as I interpret this, that would be fine. —TheDJ (talk • contribs) 09:05, 8 September 2014 (UTC)

For what its worth, when I was voting oppose on that RFC, all I wanted to oppose was the use of MP4 in production (Directly on commons). I personally have no objection to the use of MP4 on labs or other external servers. I wonder if I'm in the minority on that or if others feel similar. Bawolff (talk) 17:08, 7 September 2014 (UTC)

This RFC was only about hosting MP4 videos on Commons (including automatic conversion after upload). External tools were not discussed. Many opposes were not against this option: "my second choice on the observation that there would be nothing stopping the WMF from providing a separate transcoding space/tool for contributors to both transcode and edit video in preparation for releasing to Commons". Ruslik (talk) 17:50, 7 September 2014 (UTC)

• This tool seems to be unrelated to the RfC. The RfC seems to have discussed two things:

• Should people be able to upload MP4 files which are then stored in MP4 format on the server?
• Should people be able to download MP4 copies of files which potentially have been uploaded in other formats?

This tool seems to do another thing: download MP4 files, convert them to other file formats and presumably delete the MP4 version. If I run a program locally on my computer and then go to Special:Upload, I would get the same result. --Stefan4 (talk) 20:45, 7 September 2014 (UTC)

This tools corresponds to option: Partial MP4 support - Contributions only which clearly was defeated by option No MP4 support whatsoever. I fail to see how we can think different on this occurring on WMF owned labs hardware, compared to Commons hardware (which are literally just meters away from each other). On ... "If I run a program locally on my computer", well this is not that, it's running the program on WMF hardware, NOT your local computer. —TheDJ (talk • contribs) 09:03, 8 September 2014 (UTC)

No. That option seems to imply that files are stored in MP4 format on the servers, although those files are inaccessible to people. This tool does not store any files on the servers, unless I have misunderstood something. --Stefan4 (talk) 16:31, 8 September 2014 (UTC)

Its really rather ambigious. I think that option could have been interpreted 1 of 3 ways. First it could mean video is converted from mp4 on upload, original thrown away. Second it could mean that video is converted and kept somewhere for posterity, but generally not accessible (Or only accessible to admins or something). Last of all it could mean handling it much like we do DjVu files, where the original file is kept, and you can get to it by clicking a link on the file page, but generally we never present the original version to the user for general viewing, and they can basically just "download" the mp4 file if they hunt for it but not play in browser. (Someone could make a weak argument that perhaps this option could even mean just integrating fireogg into upload wizard). All these different options have quite differing political ramifications. I wonder if that option was specified as convert on upload and then throw away original, if it would have gotten more support. Oh well, too late now. Bawolff (talk) 02:09, 9 September 2014 (UTC)

I also disagree with your interpretation, TheDJ. Like Bawolff, I voted "oppose," but I have elsewhere emphatically supported the "contributions only" approach. I voted that way, I suppose, for two main reasons: (1) it seemed important to emphatically reject the main proposal, which I felt was a major shift away from foundational principles; and (2) a core component of the main proposal involved a secret and non-transferable contract with the MP4 patent-holders, which Prolineserver's approach does not. I think it is safe to assume that many "no" votes were not intended to oppose the "contributions only" approach. I read through them a while ago, and did not see significant opposition to the idea of converting at the time of upload in the various comments. -Pete F (talk) 07:56, 11 September 2014 (UTC)

I can fully support that, but I still think it should not be run on WMF hardware then. If people want to do this stuff, fine, but keep it on your own property. Don't open up the foundation to any potential liability. —TheDJ (talk • contribs) 09:34, 11 September 2014 (UTC)

I think the tool would be very useful, and I am not sure how it "opens up the foundation to any potential liability". If that is a concern than may be we should check with the foundation to see if they see it as a potential problem. --Jarekt (talk) 13:13, 11 September 2014 (UTC)

I don't see why community consensus on Commons should prevent development of a tool on Tool Labs, as long as it does not violate any patents (not sure about this), and the tool complies with wikitech:Wikipedia:Labs Terms of use. How is it any different from using any other MP4 converter? Hypothetically, would a tool that convert the video, deletes or garbage collects the MP4, and saves it on the user's computer be different from one which uploads it to Commons directly? Either way, if the MP4 converter is not legal (perhaps due to patent violation), then there is no doubt it should be removed. PiRSquared17 (talk) 17:21, 11 September 2014 (UTC)

If the foundation is exposed to any liabilities then it is up to the foundation to make a decision whether to keep the tool on labs. I don't see why we should worry about this at this point. Labs is sufficiently insulated from commons. --Dschwen (talk) 19:14, 11 September 2014 (UTC)

It would probably be a good idea for someone to run it by User:Coren, just to make sure there's no legal liability issue, but I agree that generally we should let the foundation tell us where there is such issues (Although it should be noted that avconv with h264 decoding is including in the default tool labs packages. One would assume if there was a problem it wouldn't have been installed). Bawolff (talk) 13:36, 13 September 2014 (UTC)

There is no licensing issues with that tool, and it complies with the Labs TOU as far as I can tell. The patent issues are ridiculously complicated and could suffice to distract a flock of lawyer for many months; but are not an issue for the Foundation as it did not write the software (Canonical is the licensee), does not provide the service, and the resulting output (which is the only thing sent to Commons) is unencumbered by patents. MPelletier (WMF) (talk) 19:27, 18 September 2014 (UTC)

Canonical H.264 license is for OEMs only (basically sold hardware). I'd suggest taking down this tool (you like doing that, right?) and removing the library until WMF's legal team figures what (patent) license they do have (encode, decode, transcoding, reading metadata). Lab's could use Cisco's H.264 binaries packages, but that messes with the FLOSS requirement (FLOSS code you can't legally compile). Dispenser (talk) 15:33, 19 September 2014 (UTC)

Spoke with Coren on IRC. He avoided giving an answer if they had any other H.264 licenses and suggests that we contact legalwikimedia.org (Somebody else contact them). H.264 licensing has enough oddities (e.g. "Free for free Internet videos") that some lawyer should research this.
Addendum: Free for free Internet videos suggests we can build a H.264 video player on Labs for iPhones/mobile devices. Dispenser (talk) 18:12, 1 October 2014 (UTC)

September 08

HHVM - speed up your page load times

It looks like the WMF recently deployed HHVM, a page-load optimizing engine, as a beta feature to WMF wikis, available to activate in your preferences. Check the box, hit save, and watch page load times go down :) Cheers, FASTILY 22:21, 23 September 2014 (UTC)

Thanks for the info.--Sphilbrick (talk) 15:34, 1 October 2014 (UTC)

September 24

Pictures that can be uploaded to Commons

The univeristy of Caen joined FlickR - the Commons and offers public domain pictures, which could be useful on Commons !

https://www.flickr.com/photos/universite_caen/with/15215336657/

— Preceding unsigned comment added by 194.199.4.201 (talk • contribs)

Though their rights statement tries to restrict usage to non-commercial uses only. Lupo 17:10, 30 September 2014 (UTC)

Or "For commercial use ... please feel free to contact us". Perhaps they could select images that can be used freely, or with a CC Attribution license, and upload those. Delphi234 (talk) 20:15, 30 September 2014 (UTC)

October 01

Images nominated for deletion (not suitable for Commons) but allowed on a local project

The issue is with these two files:

• File:GEFS MD-11 Landing in Mediterranean.jpg
• File:GEFS Landing A380 Princess Juliana International Airport.JPG

They are not licensed under a free license or in the public domain, which I believe is criteria for deletion on Commons. However, they are both used on a Wikipedia English article which benefits the article and I believe comes under fair use for that project. What should be done in this case? — Preceding unsigned comment added by Qantas94Heavy (talk • contribs)

• I don't see how they'd qualify for en-wiki's notion of acceptable non-free use, since in principle they could readily be replaced by non-infringing free-licensed images. That said, if I'm wrong and they are acceptable at en-wiki, here is how to proceed.
  1. They are certainly not the uploader's "own work," so step one to any legal fair use would be to find the actual sources (and copyright owner) and attribute them accurately.
  2. It would technically be possible to do a transwiki import to en-wiki, but it's not worth it. Just download to your machine and upload to en-wiki.
  3. On en-wiki, you'd need to fill out a copy of en:Template:Non-free use rationale. - Jmabel ! talk 05:43, 1 October 2014 (UTC)
• I think you will have a hard time making the case that these meet fair-use policy. To my eye, they're just images of random planes landing in a flight-sim, just a gallery or decoration rather than providing substantially more or different information than the text could. DMacks (talk) 05:56, 1 October 2014 (UTC)
• IMO you would probably get one, and you might get both on en-wiki. The point is that they are being used specifically on w:GEFS-Online not to show what the aircraft look like in general terms, but to show how GEFS renders them, and to give a sense of the visual quality of the game -- the visual quality of the backgrounds, the visual quality of the compositing, the visual quality of the foreground objects, the different types of lighting effects reflecting different times of day. These give the reader a valuable sense of how sophisticated the visual presentation of the game is or is not, so add materially to reader understanding of the nature and quality of the environment. The case for inclusion could be strengthened by sources discussing these things, but that is not strictly a requirement of the policy. Jheald (talk) 08:36, 1 October 2014 (UTC)

Script issue

In File:Fasana.jpg the uploader mistakenly placed the licence in the permission field; I think with this edit, although updated with this edit.

When I processed the OTRS permission statement, and used the tool in the left sidebar "PermissionOTRS" which adds the OTRS number and tag, it removed the license.

How do I contact the editor who created the script do discuss possible changes?--Sphilbrick (talk) 15:25, 1 October 2014 (UTC)

I mentioned it at MediaWiki_talk:Gadget-PermissionOTRS.js#Insert_permission_template_without_overwritting_contents, but it was reported before. Lets @Rillke: who seems to be the current (voluntary or involuntary) maintainer. Script removing licenses from images is a serious issue. By the way, many people routinely place license in the permission field and AFAIK it is one of the two proper locations. --Jarekt (talk) 18:26, 1 October 2014 (UTC)

Crumbling infrastructure

This just now:

• My Watchlist: [88da7d6c] 2014-10-01 20:17:34: Fatal exception of type Scribunto_LuaInterpreterNotFoundError
• This image: [a9fca139] 2014-10-01 20:17:38: Fatal exception of type Scribunto_LuaInterpreterNotFoundError

Maybe less of the cockamamie projects and gadgets and more of the service you’re actually expected to provide, WMF? -- Tuválkin ✉ 20:29, 1 October 2014 (UTC)

This doesn't happen for me. Is it still happening to you? (The server admin log doesn't say anything really related, although there was a problem with mw1053 which was fixed at 20:32, maybe the re-sync of that server also fixed the problem you're describing). Does it happen every time you visit your watchlist, or just randomly. Does it happen both when the experimental hhvm feature is on and when it is off? p.s. If your going to be whiny about WMF priorities, be whiny about things that WMF actually does (I'm sure there's more than enough things to chose from). WMF has nothing to do with "gadget" creation (given the technical definition that word has in MediaWiki). Gadgets are entirely made by local users. Bawolff (talk) 04:37, 2 October 2014 (UTC)

Rumor going around that issue was caused by HHVM and it only appeared briefly (But I couldn't find any technical details) [1]. Bawolff (talk) 05:09, 2 October 2014 (UTC)

Thanks for the follow up, Bawolff. It kept happening for at least a few minutes, around the time of my rant above. Then I went away for dinner and was fixed when I was back. (Apologies for the wrong use of the word "gadget". I meant things like VE or MV.) -- Tuválkin ✉ 14:38, 2 October 2014 (UTC)

Sorry I was a little snappy there. The distinction you are probably looking for is more platform engineering vs features development and product. (Although multimedia is technically in platform, it is supposed to be doing both sides of that distinction) Bawolff (talk) 16:19, 2 October 2014 (UTC)

October 03

Forcible user password change

Why on Earth all users in Wikimedia Commons are forced to change their passwords??? So what if my old password was vulneralble? It is my right to choose would I keep old vulnerable password or I will use new one. I suggest that you include option that users can keep their old passwords if they prefer to. PANONIAN (talk) 06:53, 5 October 2014 (UTC)

I think it is because you don't have changed your PW after en:Heartbleed. Keeping the old PW is a bad idea. --Steinsplitter (talk) 07:47, 5 October 2014 (UTC)

we didnt force people to change their password due to heartbleed afaik. Around the time of that bug, their was a separate bug where some users passwords were accidentally revealed to tool labs users. We expect nobody evil noticed, but just in case everyone affected was forced to change their password. If you really want the same pass, you can probably change it back after you change it to something else. Bawolff (talk) 11:22, 5 October 2014 (UTC)

Apart from that, it is not good to keep the same password for ever. --Steinsplitter (talk) 12:43, 5 October 2014 (UTC)

All things are relative. The threat model for a wikimedia account (esp. A non admin account) is fairly low risk (it's not a bank account). Personally i think keeping the same password over a long time for a wikimedia account is a reasonable convineance vs security trade off. Other considerations like how strong the password is, is probably much more important. Bawolff (talk) 14:50, 5 October 2014 (UTC)

October 06

Is this audio recording public domain?

TLDR: There's a set of valuable audio files from a vinyl record of the famous Ukrainian singer Modest Mentsinsky (died in 1935). The musical compositions themselves are in public domain, but is the recording too? And can a digitized copy of a public-domain vinyl recording be copyrighted? --YurB (talk) 12:50, 21 September 2014 (UTC)

• If the vinyl is public domain and the digital is a faithful reproduction, I can't see where a new copyright would arise (unless Ukraine has the "sweat of the brow" rule, which as far as I know only exists in the other UK). So the key would be whether the vinyl recording is in the public domain. - Jmabel ! talk 15:14, 21 September 2014 (UTC)

  Thanks! If the singer died in 1935, is it possible for the vinyl to be still copyrighted? --YurB (talk) 16:57, 21 September 2014 (UTC)

  If the recording was created in the Ukraine, {{PD-Ukraine}} would seem to imply its out of copyright. Bawolff (talk) 17:24, 21 September 2014 (UTC)

  The recordings might have been made in Stockholm as the label on the vinyls say "сьпіває Модест Менціньский, /ц./ к. надвійрий співак, Штокгольм" = Stockholm, but it may also just refer to the city where Mentsinsky lived, because you can find on the label also the following text: "Record Manufactured by the Gramophone ...little hard to read (Czechoslovakia) ... Aussig". --YurB (talk) 17:46, 21 September 2014 (UTC)

Recordings in the EU have a flat 70 years from publication; I don't know if that's relevant here. In the US, it's under copyright until 2067.--Prosfilaes (talk) 21:28, 21 September 2014 (UTC)

URAA issue? -mattbuck (Talk) 08:06, 22 September 2014 (UTC)

Not exactly; the URAA actually may not have restored the copyright, but pre-1972 audio recordings are protected by state law that has no expiration date or rule of the shorter term until federal law sunsets them in 2067.--Prosfilaes (talk) 05:36, 23 September 2014 (UTC)

Thanks you Prosfilaes for your answer. Could you please give a brief description what criteria in general are there in US for an audio recording to be in PD (so that I can figure it out in future should I deal with any similar recordings)? --YurB (talk) 18:28, 23 September 2014 (UTC)

American recordings between 1972 and 1989 have some chance of being PD, and recordings published in Iran, Iraq, and any other nation without international copyright agreements by nationals of those countries are PD. If we follow these rules, basically no sound recording is PD in the US. See meta:Wikilegal/Copyright Status of Sound Recordings Fixed Prior to February 15 1972 and w:Capitol Records v. Naxos of America.--Prosfilaes (talk) 02:16, 24 September 2014 (UTC)

EU has a flat 70-year term. This was recently increased from 50 years, and I am not sure if recordings which were fine under the old 50-year term remain fine.

USA normally protects all pre-1972 sound recordings until the end of 2067, presumably without exception. --Stefan4 (talk) 14:48, 28 September 2014 (UTC)

Thank you all for useful answers. This is indeed good to know, although of course a bit sad. My last question, just to make sure I understand this correctly - in USA all pre-1972 recordings are protected, including those produced outside of US? If so, what about materials like the Filaret Kolessa phonograph cylinder collection and similar late 19^th and early 20^th century folklore recordings hosted on Commons? Best, YurB (talk) 10:10, 29 September 2014 (UTC)

These are not national laws, they're state laws, so they aren't necessarily going to be interpreted the same everywhere in the US, but w:Capitol Records v. Naxos of America ruled that British recordings out of copyright in the UK would still be in copyright in the US. In the case of those recordings, Nevada and Florida and I believe other states require "the consent of the person who owns the master phonograph record, master disc, master tape or other device or article from which the sounds are derived", thus the archive could authorize reproduction of cylinders they own. (Others have said things about common law copyright, but I do not understand how that interacts here, if it does.)--Prosfilaes (talk) 20:31, 30 September 2014 (UTC)

One way to interpret the situation is not that "all pre-1972 recordings are definitively copyrighted" but rather that "very few sound recordings are definitively out of copyright in the US." Prosfilaes mentioned certain post-1972 recordings and recordings published in countries such as Iran and Iraq that lack copyright relations with the US. (It would be interesting to know if pre-1972 recordings that are works of the US government are out of copyright in the US.) On Commons, it appears that some pre-1972 recordings have been uploaded (see {{PD-Edison Records}} and the {{PD-US-record}} talk page) but the copyright situation is far from clear.

For finding uncopyrighted audio, a situation to consider is when a motion picture is out of copyright (i.e. Night of the Living Dead.) From what one understands, under US copyright law, a "sound recording" is a reproduction of audio by itself, i.e. a phonograph record or an audio CD. On the other hand, for an audiovisual work such as a motion picture, the audio portion is considered to be an integral part of the work for copyright purposes and is not a "sound recording." This would seem to suggest that the audio portion of a motion picture would be subject to federal copyright if the motion picture itself is under copyright but otherwise would be out of copyright. --Gazebo (talk) 04:18, 1 October 2014 (UTC)

Sound recordings from Iran, Iraq and a few other countries without copyright relations are exempt from federal copyright (meaning that post-1972 sound recordings are in the public domain in the United States if they come from any of those countries, provided that the recordings have been published). Whether pre-1972 sound recordings from those countries are in the public domain or not is up to state law to decide. --Stefan4 (talk) 14:00, 7 October 2014 (UTC)

Thanks to all of you for detailed comments. This is all very useful info to me. --YurB (talk) 21:41, 7 October 2014 (UTC)

September 23

Does the foundation require Commons to only allow things that are free in the world's most restrictive possible copyright regime?

Because that's what's being argued at Commons:Deletion_requests/File:Chadwick.jpg. Adam Cuerden (talk) 22:31, 28 September 2014 (UTC)

That is what wmf:Resolution:Licensing policy says: content must be free according to Freedomdefined:Definition, and Freedomdefined:Definition says that there must not be any restriction on where the material is used. --Stefan4 (talk) 22:37, 28 September 2014 (UTC)

That's ridiculous. It's a seven-year-old resolutioon. If the foundation wants to overthrow Commons policty, that may be their right., but I'd quit Wikipedia this minute. Adam Cuerden (talk) 23:03, 28 September 2014 (UTC)

The statement made in the header is not really relevant in the specific case. Anyway one in practice looks at the US copyrigth law and the local law. However this does only apply to "normal" countries. I dont think we have to respect North Korean law and other very restrictive regimes.Smiley.toerist (talk) 23:14, 28 September 2014 (UTC)

You are looking at the part about exemption doctrine policies, which tell whether non-free content can be used and which says that only the laws of some countries need to be considered. The important part here is the definition of a free content licence, which is a licence which satisfies Freedomdefined:Definition. --Stefan4 (talk) 23:23, 28 September 2014 (UTC)

(Edit conflict) Stefan4 is right, that is what the text says. The WMF needs to change it, unless we want to follow the ridiculous notion of obeying Mexico's 100 years after the death of the author copyright term and very expansive definition of copyrightable works. Smiley.toerist IP law is the only issue at hand, and we still follow North Korean copyright; it's unremarkable, and North Korea remains part of the community of nations. —innotata 23:30, 28 September 2014 (UTC)

Regardless of what the letter of the WMF resolution or free content definition says, it is the spirit that matters. WMF resolutions only trump Commons policy if the WMF chooses to enforce it. And they certainly aren't going to delete every Commons image in existence if North Korea suddenly says that every image ever created is copyrighted and the copyright owner cannot license away that right. -- King of ♥ ♦ ♣ ♠ 23:36, 28 September 2014 (UTC)

Yeah, there are already some countries where CC licensing and releases into the public domain are in a grey area…

The resolution says it "may not be circumvented, eroded, or ignored by local policies". So we ought to contact someone at the Foundation and ask them, well, to change the policy. Unless someone else does so, I'm going to ask once once I get time in the next few days. —innotata 23:44, 28 September 2014 (UTC)

I took the example of this image. It is in the public domain in the United states. No doubt about that. And since it is a US image, it is therefore also in its own country. However it is not in the public domain everywhere, so it stands to be deleted on Commons. Yet if you try to upload a US-PD image to Wikipedia, a Bot transfers it to Commons to be deleted! Hawkeye7 (talk) 04:02, 29 September 2014 (UTC)

It is in the public domain in all countries which respect the copyright status of the country of origin. I don't have an exact figure, but I believe that it includes most countries in the world. Regards, Yann (talk) 07:24, 30 September 2014 (UTC)

I find this discussion quite confusing. Last time I checked we only had the requirement for images to be PD in the US (where the servers are) and in the country of the origin. We do not care about other countries, and do not have to be familiar with their laws. And nobody is planning to delete this image. --Jarekt (talk) 10:36, 30 September 2014 (UTC)

Well, Stefan is saying that the WMF currently requires with their licensing policy, and he isn't obviously wrong! Now that I've gone and re-read the Freedom Defined definition as I planned to write to people at the WMF, I see it only says there can be no restrictions on "where" a work can be used. In context, that sounds like it's referring to what media a work can be used in, but it's not as clear as possible and I'm still not completely reassured. (As for U.S. government works, at least some are copyrighted outside the U.S.) —innotata 17:50, 30 September 2014 (UTC)

Well, restrictions on geographic regions and media type are both important, so it makes sense to require both in order to claim that a file is free. I'm not sure if Commons should follow that slavishly, though. For example, many books are distributed by online bookshops in lots of foreign countries. Swedish books tend to be distributed by online bookshops in all Nordic countries (although of course in very small numbers outside Sweden and Finland), and British and American books tend to be distributed by online bookshops in lots of other countries. If the standard practice is that books are distributed in a hundred of countries, then an image isn't suitable for use in books, unless the image is in the public domain in all of those countries. --Stefan4 (talk) 14:21, 7 October 2014 (UTC)

That image is a US government work, so the rule of the shorter term may or may not apply; given that the US has not given up the right to make copyright claims outside the US, and some courts have ruled that the rule of the shorter term only applies running out the term of copyright, not stuff like non-renewal or this, it's unclear how courts across the world may rule on the matter.

As for the w:rule of the shorter term, a quick glance at that page shows a lot of nos, and Canada's rule excludes the US. Running down the largest countries in the world, China no, India yes, US no, Indonesia no and Brazil no. That's two billion people without the rule right there.--Prosfilaes (talk) 21:54, 30 September 2014 (UTC)

Stefan's comment there is nonsense. Yann (talk) 04:58, 29 September 2014 (UTC)

I'd say the general rule we've been following is: If the original copyright holder does not consent to its use under a free license, but it is nonetheless public domain in the US and the source country, then it is OK for us to use. If the copyright holder consents, but it is not public domain in the US and/or source country, then s/he must consent in every country in the world where it is legally possible to do so. I feel that once you start getting into public domain law, it's in an area that Freedomdefined:Definition wasn't geared towards specifically. -- King of ♥ ♦ ♣ ♠ 02:12, 3 October 2014 (UTC)

September 29

Lack of EXIF metadata

Hi. I would greatly appreciate some help. When i upload photos directly from my iPhone to Commons, how come the EXIF metadata is never added to the Commons files information? Thanks.MoTorleeb (talk) 13:04, 6 October 2014 (UTC)

i believe iphones have an option to remove all exif data that is on by default (due to some moral panic over people unwittingly revealing their location in gps exif). Bawolff (talk) 15:31, 6 October 2014 (UTC)

We once had a case of a husband in trouble because he used his iPhone to upload images of his wife's private parts to Commons, and now his geocoded images was plastered over his house when when viewed in Google maps. The poor guy was sheepishly asking how can he correct this issue. I believe IPhone guys were trying to avoid that sort of trouble. So MoTorleeb (and other iPhone users), keep track for which images you would like to keep full EXIF, and for which you would rather not. --Jarekt (talk) 15:50, 6 October 2014 (UTC)

OK. Thanks Bawolff & Jarekt. Really appreciate the thorough responses.MoTorleeb (talk) 19:06, 6 October 2014 (UTC)

There's some more information at http://stackoverflow.com/questions/16297730/image-upload-from-iphone-strips-exif-data#answer-16361254 Bawolff (talk) 02:03, 7 October 2014 (UTC)

Experimenting with using VIPS to render large tiff files

Hi all. We are currently experimenting with using VIPS to render large (>50 megapixels. Previously these files didn't render at all) tiff files. So far it looks successful for most files (Certain files over 350 megapixels seem not to work, especially LZW encoded ones. I've found about 3 examples). At the same time we are adding sharpening to these (the > 50MP) files, like what is currently done with jpeg files. Please test out different files, let me know if there's any problems, or things that could be better, etc. I'd also like to confirm that sharpening settings are appropriate and wanted (I've heard lots of people ask, and I think it makes thumbnails look much better, but would good to get a confirmation on that from you folks). If results are positive, I'd love to extend this to tall tiff files (Assuming you all agree, we will obviously have a community discussion about it. I figured its ok to enable on the large files without discussion because prior to this they were just broken).

Related links that might be of interest to some people: https://lists.wikimedia.org/pipermail/multimedia/2014-October/000861.html, https://gerrit.wikimedia.org/r/#/c/164476/, bugzilla:52045.

Some example files that used to not render but now do:

• 
• 
• 
• 
  This file is 1 gb big!
• 

Some files that didn't work: file:Amelia earhart received by president coolidge.tif,File:Carr wilbur j honorable.tif (Not sure about these two, they work locally Appears to be an issue with (greyscale?) images using 16bit depth) file:Zoomit2.tif takes too long to render and times out (Its the largest tiff file on commons in terms of megapixels). Thanks everyone, BWolff (WMF) (talk) 00:41, 3 October 2014 (UTC) (Aka User:Bawolff)

@BWolff (WMF): A couple of thoughts:

• It would be good to go bigger than 1280 wide for the image. Given the originals are such good quality, it would make sense to offer versions at least up to 4000px wide that people can click through to directly, and examine using the zoom in their browser, without having to download the original-size 50 Mb image.
• Quality is not good, particularly for engraving. By the sound of it you are not using an anti-aliasing filter, and then you are sharpening. That is a bad combination for engravings, and other images with sharp black-and-white lines or edges. It gives a strong risk of aliassing artefacts where there are regular structures (eg parts of sky done by a ruled-etching machine), and "jaggies" on curves. For examples of the latter, look at eg File:Lubinus Duchy of Pomerania Map 1618 monocromatic.tif at 1280px and note the jaggies on the curved lines of the larger letters -- eg Balthice, Maris Pars, Poloniae Pars, etc.

Further aliassing artefacts can be seen in the poor quality of lines in File:Site_Plan_-_Christ_Church,_2304_Highway_17_North,_Mount_Pleasant,_Charleston_County,_SC_HABS_SC-877_(sheet_2_of_11).tif, the lack of even-ness in the shading of the roofs, and the poor quality of the rendering of the text, when the image is viewed at 1280 px.

On File:Topographical atlas of the city of New York, including the annexed territory showing original water courses and made land. NYPL1527362.tiff there is visible ringing in the words "Topographical Atlas" at 1280px -- again this is likely to be due to the over-sharpening.

Given such good originals, we ought to be doing much much better than this.

There is a right way to do an image-downsizing and sharpening, and it is to use a Lanczos filter (or the very similar Mitchell filter used by Image Magick -- but unfortunately not IM in thumbnail mode). We're only doing this downsizing once, to produce reference versions of the images which will then be cached; so we ought to do it right. Jheald (talk) 08:01, 3 October 2014 (UTC)

For comparison, I have uploaded

• File:Site Plan - Christ Church, 2304 Highway 17 North, Mount Pleasant, Charleston County, SC HABS SC-877 (sheet 2 of 11) - IM resize.jpg
• File:Lubinus Duchy of Pomerania Map 1618 monocromatic - IM resize.jpg

both resized with Image Magick pretty much out of the box, using eg convert Lublinus.tif -resize 1280x1280 -quality 100% Lublinus.jpg

(Note that by default MediaWiki currently uses the much lower quality IM thumbnail command, which does no anti-aliassing. Effects of the crudeness of the thumbnail command can already be seen in the reduction from 1280 -> 800 px, for example jaggies in the edge of the letter V.

GIMP should also be avoided, because it doesn't use an anti-aliassing filter, even when specifically requested to.)

If you compare each of them at 1280px, note the even-ness of the shading of the roofs on the plan of Christ Church, the more even-ness of the text, and the better quality of the lines. On the map of Lublin, note the much better quality of the letter-forms of the main caption, and of the calligraphic flourishes on words like 'Balthics' and 'Maris Pars'. Jheald (talk) 09:07, 3 October 2014 (UTC)

I'm pleased to see this is being handled and that WMF devs are investing a little time into it. Technically, this does not seem to be an easy thing to get right (based on the bugzilla discussion behind it) but worth it considering we are highly likely to have many archive quality donations of 50MP TIFFs in the next few years. The interim solution I used for a large number of TIFFs of diagrams from the National Parks Service of linking to a PNG copy has been problematic, as re-users tend to be confused when confronted by piles of unrendered thumbnails and give up rather than looking for the alternative versions, or think the file was mis-uploaded. --Fæ (talk) 08:50, 3 October 2014 (UTC)

thank you for this much needed work. is there a problem rendering thumbnails slowly? as we scan the national archives works there will be millions more. (glad you like the flamethrowers) Slowking4 ♡ Farmbrough's revenge 12:10, 7 October 2014 (UTC)

This effort affects only one of my uploads, the TIFF works now as is. Will a bot handle the cleanup, or are we supposed to do this manually? Just deleting the dupe and the cross references could be a bad idea, if somebody used the dupe outside of Wikimedia projects. –Be..anyone (talk) 11:06, 9 October 2014 (UTC)

October 04

Obfuscating image's sources?

Shouldn't we fill our {{Information}} template's source fields with the URL of the page that describes the image, and supplies a link to the high resolution image? Isn't it always a mistake to supply only a link to the actual image, because that makes it essentially impossible for anyone to verify key information, like the author and publication date?

I have uploaded one hundred or more images whose ultimate source was the city of Toronto archives, or the Toronto public library, but which I found republished in local magazines, newspapers or websites.

When the page where I found the image has encough information on the image's date to verify that the image is {{PD-Canada}} I don't try to find the original description page in those archives. I find them very hard to navigate. If I have found enough information to confirm an image is old enough to be in the public domain I don't think I have an obligation to try and navigate the difficult archive.

There is another contributor who has mastered the archive-fu to find those original pages. I am happy when he or she finds the original page, and finds the version there is of a higher resolution than the version I uploaded, and they upload the higher resolution version.

However, afterwards, they routinely remove the URL to the original web page from which I uploaded the original version, and they replace it with the URL to the high-resolution image they uploaded. Just to be clear, they don't fill the source field with the url of the original site's description page, they fill with the URL to the actual image. As I noted above this makes it almost impossible to confirm any information about the image.

1. Is there ever an excuse to fill the source field with a link to that actual image, and not the page that described the image?
2. When someone finds a source page with a higher resolution version of an image, shouldn't they still retain the original URL, moving it perhaps to the "other versions" field? This means that an external links search for the original source page will still generate a hit.

P.S. I chose not to link to the specific images, or the specific discussion I referred to above. I think I have given enough information that more specific details aren't needed. I would prefer for this discussion to be just about the issues. Thanks! Geo Swan (talk) 23:28, 8 October 2014 (UTC)

Yes, it's best to provide a link to a page that contains information on the image, and that shouldn't be removed. It's pretty obvious good practice for the reasons you give, and I'm sure it's discussed before. What I like to do is add the link to the high-resolution version of the image to the source field, unless it's easy to find from the other link. (Don't put it in the other versions field, that's for other versions of the image within Commons, see Template:Information). —innotata 00:08, 9 October 2014 (UTC)

I agree with the above and I’m surprised it isn’t standard policy. It would be useful to archive a copy of this discussion in Template talk:Information. As for storing more than one url (incl. a high res original) under |Source=, I routinely do it. When I was warned that this confuse the automated procedures that follow Template:LicenseReview, I kept in |Source= only the contextual url (which contains, i.a., authorship and licensing information) and stored the high res link in a separate field, as in, e.g., File:07-11_Albert_Khan114.jpg:

| source = http://www.fotopedia.com/items/mslorraine-3bhk4byfXAI

| other_fields = {{Information_field |name=Original url|value=http://images.cdn.fotopedia.com/mslorraine-3bhk4byfXAI-original.jpg}}

I kept using more than one url in |Source= for PD files, such as File:MaxibomboEstrelaLx(Benoliel1913)57-1.jpg, as those do not require going through Template:LicenseReview, but it would be trivial to change to something akin the alternate presentation used above the many Commons images with multple source references. -- Tuválkin ✉ 01:00, 9 October 2014 (UTC)

October 09

Permissions on an image within an image

When an otherwise free image is blocked from use because it captured a poster, painting, etc, created by someone else, can the author of that other work agree to allow their image to be used here in the larger image, without eroding their intellectual property rights on the image, in general?

About ten days ago I uploaded a bunch of images related to Toronto's crack-smoking mayor Rob Ford. Two of the images included prominent instances a clever poster mocking Ford. Those two images were challenged, on the grounds the photographer couldn't release the poster, which was created by someone else.

Well, I found a flickr gallery of over four dozen instances where this clever poster was used. Those image are marked "all rights reserved."

I wrote to the owner of the flickr gallery, who confirmed he created the clever poster.

I wrote him back, asking him to allow us to use the two images created by other photographers, that include the clever poster.

Is it even possible for him to allow images that use his poster to be freely used here, while still retaining full rights to the poster? Or, if he allows these two images to be freely used does that mean I accidentally tricked him into generally releasing rights to his clever poster?

I wouldn't want to do that.

When Senator Barack Obama first ran for POTUS several posters were made that had simple images of him, using large blocks of 3 or 4 colours. Each of those Obama posters had a simple one word message. One was "Hope".

The clever Ford mockery photo uses the same kind of large blocks to make an image of Ford that made him look like Italian dictator Benito Mussolini. It had the one word message "Nope". Geo Swan (talk) 13:22, 9 October 2014 (UTC)

So if I understand you correctly, you are hoping to upload posters created by an artist, but these posters incorporate a photograph which was taken by someone else. In this sort of situation, unless both the artist and the photographer of the original photograph have agreed to license their works under a free licence, the poster can't be uploaded here. The artist may be able to argue that he was making fair use of the photograph and so his posters do not infringe the copyright in the photograph, but Commons policy does not permit reliance on the doctrine of fair use. — SMUconlaw (talk) 18:00, 9 October 2014 (UTC)

• It is the other way around. I uploaded a street scene that included a telephone pole that had a poster of "Ford-O-lini" taped to it; and I uploaded a demonstration where one of the demonstrators was carrying a protest sign bearing the "Ford-O-lini" image. The photographer had released the photos under a free license. It was the position of the nominator and closing admin that the Ford-O-lini images were large enough that the permission of the artist who created the Ford-O-lini image would be required.

I've exchanged a couple of email with the artist, who wants to retain the IP rights to his image. In his last message to me he seemed to think we didn't need his explicit permission to contain photos that captured his posters, together with other elements, like passing cars or protesters.

If only it were that simple. I overlooked the need to get the permission of the artist of the poster when I uploaded these two images. Our rules do require his explicit permission.

Since he thinks we don't need his permission to use photos by others that captured images of his poster he might easily agree. What I would like others' opinions about is if he agrees to let us use the Ford-O-lini images captured in the other photographer's photos will that imply that he has unknowingly generally released permission to the Ford-O-lini image?

Here is the artist's own gallery of Ford-O-lini images: https://www.flickr.com/photos/ericparker/sets/72157640420719996/ Geo Swan (talk) 05:11, 10 October 2014 (UTC)

I guess the trouble with giving permission is that that includes permission for derivative works -- which in turn potentially includes cropping the poster out of the documentary image to reconstitute it is a stand-alone image in its own right.

en-wiki could probably use one of these photographs showing the poster under fair use (as could anybody else in the United States writing about the protest); but of course even then the fair-use content allowed would only be a single image, in a very definite context. And it would be unavailable on most other wikis. As for claiming incidental inclusion, you're quite right that that won't run, if what we're including is actually a key feature of the image for the purpose we're using it.

If you want to go ahead, it seems to me the best way forward would be either a photograph of the poster with some action going on in front of it, that partly interrupts it, so that nobody could extract a full clean version of the poster from it. Or a distorted version of the poster, eg on the curve of a banner. But, yes, if such a prominent piece of art being used distinctly as the focal interest of the image - not just an incidental piece of protest imagery - I think we would really want a release from the poster artist that he was okay with the use in this image and derivatives made from it (while holding all other rights in the poster reserved), in order for us to consider the image completely free.

Of course, if some third party really wants to use the poster, 99% of the time they won't care about copyright like we do, so they'll just pull it off the internet without thinking. Or they'll be using it in a context covered by US fair use or Canadian fair dealing (which is pretty generous). So in practice it's probably unlikely that many people would go to the extent of cutting out the poster from our picture of it, just to have a legally free copy. But that's for the artist to assess. Jheald (talk) 07:21, 10 October 2014 (UTC)

Note that copyright owners who license their works under a free licence do not give up their copyright in the works. However, having given a free licence, people are entitled to reuse the works according to the terms of the free licence. A copyright owner would only be able to prevent such reuse if it was not compliant with the terms of the free licence (for example, a reuser fails to attribute the work to the copyright owner, or passes it off as his or her own work).

In the situation above, we would need free licences from both the photographer of the posters and the author of the posters in order to host the photographs in the Commons. Furthermore, as I mentioned above, if the author of the posters used an image of Rob Ford which he did not personally own (e.g., a news photograph he found online) as the basis of the posters, we would also need a free licence from the original photographer or artist. The latter problem does not arise if the author of the poster drew his own image of Ford. — SMUconlaw (talk) 11:03, 10 October 2014 (UTC)

• Thanks everyone for your fine advice. I won't upload an image here. I may upload a "fair use" image, if I can find enough references to justify specific coverage of the Ford-O-lini poster.

I think I will ask Mr Parker if he still has one of the T-shirts available.

Cheers! Geo Swan (talk) 14:25, 10 October 2014 (UTC)

Media needing categories

For a long time the category Category:All media needing categories as of 2012 (...of 2013, ... of 2014) had sub-categories by day. Those sub-categories disappeared and the categories like Category:Media needing categories as of 4 February 2014 are invisible. Why did the sub-categories were deleted (or disappeared otherwise)? Most of the time it is the best way to categorise by upload dates, because people upload series with the same theme the same day. Traumrune (talk) 19:38, 9 October 2014 (UTC)

I guess that's because DschwenBot added a wrong category (Category:Media needing categories in use in galleries) to the day categories instead … Ping User:Dschwen.    FDMS  4    20:02, 9 October 2014 (UTC)

Uhm, what? Do you want me to add the ... as of 2014 category to each day category? I guess I can totally do that. --Dschwen (talk) 20:33, 9 October 2014 (UTC)

Actually I have a betetr idea, why don't we make Template:TlUncategorizedHeader insert thiose categories? That will fix things retroactively. --Dschwen (talk) 20:34, 9 October 2014 (UTC)

Something that fixes the categories retrospectively is a very good idea. Traumrune (talk) 19:18, 10 October 2014 (UTC)

October 10

Call for OTRS administrator applicants

The OTRS administrators are considering expanding the admin team. We invite all community members to review the call for volunteers on Meta-Wiki at m:OTRS/Call for administrators.

We would like to keep questions centralized, so please direct all discussion to the talk page: m:Talk:OTRS/Call for administrators.

On behalf of the OTRS admin team, Rjd0060 (talk) 01:42, 11 October 2014 (UTC)

Mysterious categories

I just noticed Category:Files with no machine-readable source and Category:Files with no machine-readable description that are filling up through some automatic process. Anybody knows where they come from? --Jarekt (talk) 02:41, 8 October 2014 (UTC)

My guess is that this is related to the automatic meta data extraction needed for the media viewer.--Dschwen (talk) 03:09, 8 October 2014 (UTC)

Yes, its supposed to be used to identify images that media viewer can't display properly automatically, so they can hopefully be fixed as appropriate. User:Tgr (WMF) is the person working on this, so he'd be the best person to ask. See [3] and Special:TrackingCategories. Like all tracking categories, the category name can be changed (or outright disabled by using the name "-") by editing the relavent MediaWiki namespace page. Bawolff (talk) 04:13, 8 October 2014 (UTC)

It seems naff to either leave these as redlinks on image pages, or in fact to use categories to do this rather than creating a backlog report/JSON query that could be pulled into other tools if needed. There are a lot of possible issues that might be added as categories but we normally choose to avoid the approach of using dummy categories as error flags. Could a more elegant alternative be chosen please? --Fæ (talk) 05:33, 8 October 2014 (UTC)

They're not red links any more (That was an easy complaint to address :P). This cannot easily be a special query page since the relavent information not exactly in the best form in the database currently (I suppose it could have been a page prop. Personally I think tracking categories are better than page props for this sort of thing, but that's just my opinion). You can easily get a list of things in a category in json format if you need it for other tools, via the API. Commons makes extensive use of hidden categories (897,875 at current count, albeit many for non-error related internal tracking) for tracking of maintenance thingies afaik, so I'm not sure I see your point about commons choosing to "avoid the approach of using dummy categories as error flags". I don't particularly see how using categories to categorize things based on some condition is inelegant, and there is precedent for MW automatically adding categories to track situations that should be fixed. That said, what would you consider an elegant solution? Bawolff (talk) 07:00, 8 October 2014 (UTC)

Bawolff, an alternative solution is the use of empty tag templates. They work well with CatScan2 and nobody can see them. I am not arguing that they should be used in this case, but it is an option. --Jarekt (talk) 11:47, 8 October 2014 (UTC)

That's not really an option in this case, as the category is detecting something missing from a page, but mw cant really add a "mysterious" tag template without editing the page, where categories can be added mysteriously. I suppose special:pageswithprop which is a possibility for something like this is close to the idea of a tag template. Bawolff (talk) 12:12, 8 October 2014 (UTC)

Bawolff, current "mysterious" tag templates are added without editing the page - through other templates. --Jarekt (talk) 19:03, 9 October 2014 (UTC)

There are probably several alternative static or live reporting and database based solutions, including piggy-backing on wikidata using intersection reports to do something meaningful. The key issue here is if this category is a "WMF official" way of marking several million image pages with missing authors, then there is no rationale to stop a volunteer adding millions of images to more (slightly pointless) huge backlog categories for date, artist, medium, VIRIN, location, etc. A solution that enables user created tools to pull a live JSON report for these missing parameters in templates for classes of images (such as those under a master category or including a chosen creator template) would be far more useful and avoid lots of uneditable hidden categories that few will ever use and will tend to obscure more targeted hidden categories.

Hm, reading this back, I appear to have answered your question with what was essentially my first statement. I am not going to invest my volunteer time researching and designing a better solution, I'm sorry if that is your expectation for what I have to do in order to express an acceptable viewpoint on whether the current approach is elegant or naff.

@Tgr (WMF): Should we raise a bugzilla request to have these categories removed? I'm assuming that correspondence here with volunteer only accounts is not a WMF response. Thanks --Fæ (talk) 13:09, 8 October 2014 (UTC)

Re Fæ: This is not an official response, its not my feature (Although if it was my feature, I would probably do it the same way). My goal here (as well as in the majority of my edits to the VP) is to use the fact that I keep a close eye on MediaWiki development in order to respond to technical question quickly and accurately. That said, your complaints don't really make sense to me. You're concerned that this will result in an explosion of maintenance cats (Which would be bad because? Not like we're running out). But I find it hard to believe that this new category will encourage people more than say Category:Images without source and friends. You can get a live JSON feed of things meeting this criteria (Sortable either by date or alphabetically) at [4]. You can also do intersection with other categories, or templates via the search engine. As far as I can tell, you're suggesting that we should use a system exactly like categories, except not called categories. Re-inventing the category wheel seems like it would be a silly use of developer resources. In terms of filing a bug to get the categories removed - As I said above, like any tracking category, they can be disabled by any Admin (Although if people feel that to be neccesary, I think it would be polite to chat with tgr first before resorting to that). Last of all, in terms of expectations, I don't expect you to design an entirely new solution, but I don't think its unreasonable to expect you to state clearly what you want that is not present in the existing solution. Bawolff (talk) 14:59, 8 October 2014 (UTC)

So, what's wrong with files like this or this? They're correctly tagged with source={{Own}} but show up in Category:Files with no machine-readable source nevertheless? --El Grafo (talk) 08:48, 8 October 2014 (UTC)

Hmm, appears to be categorizing file redirects (e.g. File:2014_Paczków,_Rynek_35_12.JPG, but when you click on the link in the category it goes to the normal image) as having no machine readable data. That would be a bug. Good catch. Bawolff (talk) 15:16, 8 October 2014 (UTC)

Fixed. File redirects should no longer have the tracking category [5]. At least no new file redirects will be added. Ones already in the category may stick around until next null edit. Bawolff (talk) 02:12, 9 October 2014 (UTC)

Apart from "sticking it to the man", is there any good reason why this solution is being opposed here? Now that the categories are not redlinks anymore I don't see why this is naff (learned a new word today), or unelegant. This seems like a rather helpful tool to address cases of badly formatted metadata. --Dschwen (talk) 14:35, 8 October 2014 (UTC)

There is an issue of back-door WMF standardization of Commons without community agreement or discussion (I think, I would be happy to be put right on this if you can supply a link). There is no way that ingestion templates or similar variations can be auto-detected by however this works for WMF standardization of how license, description, author and source must be formatted on our image pages.

As for naff, it's a very British term with roots deep in Polari. Gentlemen such as myself find it convenient, even if we accidentally forget that really only a minority of the omi-palone are going to pick up on it and rarely the feely.--Fæ (talk) 14:50, 8 October 2014 (UTC)

The categorization is based on if an image meets Commons:Machine-readable_data, which does not come from WMF (In the future, people want to move to wikidata-ish things, which is a whole other bag of fish). Bawolff (talk) 15:03, 8 October 2014 (UTC)

I suggest we focus on what benefits the project first, rather than quarreling on "who had the idea". Honestly, we need standardization to get enforced. The community did provide a standard through {{Information}} and related templates (as well as countless helper templates such as {{Own}}). The nature of the wiki makes it hard to enforce such a standard though. --Dschwen (talk) 16:08, 8 October 2014 (UTC)

+1. But it seems there are bugs in the code. Both categories contain perfectly valid file pages. Jee 16:26, 8 October 2014 (UTC)

Any bugs other than the redirect bug Bawolff commented on above? --Dschwen (talk) 16:31, 8 October 2014 (UTC)

Most files in Category:Files with no machine-readable description are files using {{Artwork}}. For {{Artwork}}, "description" is "unnecessary" if "title" is provided. Jee 16:44, 8 October 2014 (UTC)

This may just be a matter of adding the right machine-readable marker in {{Artwork}}, then, although it may not be so straightforward (see Template talk:Art Photo#Issue with MediaViewer for more information). I don't want to make edits to widely-used templates when tired, so I'll look into this when I'm fresh tomorrow. Guillaume (WMF) (talk) 18:45, 8 October 2014 (UTC)

People seem to focus on the 'presence' of this information (as perceived by their human eyes reading the file description page), but that's not what this category is about. It's about visualizing our (as a movement and platform) current capability to parse and process this highly complex and disorganized information, and to highlight where we currently are not able to do that (either because we forgot to make use of an annotation that makes something machine readable, or because the page simply is not machine readable. We as a community need to fix this and this will help us get further with that process. —TheDJ (talk • contribs) 20:00, 8 October 2014 (UTC)

A quick note as it's late in my timezone: If you must assign blame, blame me, not Tgr. He asked me if I thought this would be controversial, and considering that we routinely use dozens / hundreds of maintenance categories on Commons, I felt this wouldn't be an issue. Standardization of machine-readable metadata according to the existing Commons system is something I think we can all get behind, and my feeling was that the help of the WMF in this context would be welcome.

I've been tasked to lead a File metadata cleanup drive to do just that, by finding and fixing files without an information template, and by adding machine-readable metadata to templates that are there. These tracking categories are one way of identifying those files and templates that need fixing; they also allow us to get an idea of how many files are concerned, and to measure progress as we fix them.

Another way to identify these files is a tool (still a prototype) I've been working on to do this across all wikis; I'm hoping to add Commons in the next few days (it needs special work due to its sheer size). As soon as we have these tools ready, I'll be communicating more, and you'll also see me editing templates as part of this cleanup.

The WMF is committed to actively helping wikis achieve better file metadata standardization, and Commons is leading the way with the system of machine-readable markers created a few years ago. A majority of files on Commons already have machine-readable metadata, and a lot more will after I or others fix machine-readable markers in a few templates like {{Artwork}}. The tracking categories will just help all of us get to the long tail of (mostly ancient and forgotten) uploads that don't yet use the standard Commons system. Guillaume (WMF) (talk) 18:45, 8 October 2014 (UTC)

To be clear, I hope my comment didn't come across as blaming tgr, I just wanted to make sure it was clear that I wasn't speaking on his behalf. Bawolff (talk) 19:44, 8 October 2014 (UTC)

It didn't, but seeing how the rest of the discussion was going, I wanted to make sure that if there was going to be heat about this, it was on me. Guillaume (WMF) (talk) 06:24, 9 October 2014 (UTC)

Thanks Guillaume (WMF) for improving the templates; it is highly appreciated. Jee 03:14, 9 October 2014 (UTC)

Thanks Bawolff for fixing the redirect bug! As for the title issue, ideally artworks should have a separate description and a title (which is not miles long) - if you look at e.g. File:'SANTA_ANA_RIVER_AT_CHINO_CREEK,_RIVERSIDE_COUNTY.'_This_is_an_oblique_aerial_view_to_the_north,_looking_over_the_flooded_fields_between_Chino_Creek_and_the_Santa_Ana_River,_HAER_CAL,33-CORO.V,1-2.tif, the "title" clearly has an actual title part and a description part and from the point of view of the reuser mashing the two together is unhelpful.

If we want to keep the status quo anyway, we can either make the CommonsMetadata API fall back to the title for its ImageDescription field if there is no separate description, or we can rename the category to "no machine-readable title or description" and only add it if neither ImageDescription and ObjectName are present in the API output, neither of which seems like a great solution. --Tgr (WMF) (talk) 06:27, 9 October 2014 (UTC)

• Tgr (WMF): See the documentation of {{Artwork}}, {{Photograph}} and {{Art Photo}}: "description: Description of the content of the artwork (using multilingual templates like {{En}}). Often unnecessary in case of paintings when title is used." We are using these templates for a long while; so making "description" a must now means the need of a lot of editing. Jee 06:44, 9 October 2014 (UTC)

• Note that these templates also exist on other projects. I have just created three categories (the description, source and author ones, not sure if there are more of them) on English Wikipedia. People who are active on other projects might wish to create the categories there too. On English Wikipedia, it seems that many files with fair use rationales end up in categories for files missing source and author. --Stefan4 (talk) 22:28, 9 October 2014 (UTC)

I'm cleaning out the redirects that ended up in the tracker categories. That should remove quite some noise. I filed bugzilla:71950 to keep track of the title/description bug. Multichill (talk) 12:08, 11 October 2014 (UTC)

And another bug (bugzilla:71957) for the fact that images in Category:Images without source don't end up in Category:Files with no machine-readable source. Multichill (talk) 15:26, 11 October 2014 (UTC)

Input requested re: categorizing categories for NRHP and similar things

I'd like some input related to a discussion I've had here with User:Look2See1 about categorizing categories such as Category:National Register of Historic Places in Nevada County, California and Category:California Historical Landmarks in Humboldt County, California. These are for the heritage registers National Register of Historic Places (NRHP) and California Historical Landmarks (CHL), respectively, but the discussion could apply to other heritage registers and similar things.

These categories contain many different kinds of things -- buildings, geographical features, places where something historic happened, entire towns, parks, trees, historic districts, ships, things that don't even exist any more, and probably more. When I looked at these categories, it didn't make sense to me to have them under building categories because 1) a "historic place" or a "historical landmark" is not inherently a building and 2) not everything in the categories is a building. Therefore, I removed the building categories. I figured that anything that was a building could go individually under applicable building category(ies).

Look2See1 disagreed and undid my changes. After undoing each other's edits a couple of times, I asked for an explanation and Look2See1 told me that "most editors" categorize that way because most of the things in the categories are buildings. (You can see the linked discussion for exactly what was said.) I've been misled before when I took one editor's word for something, so I'd like to hear from others as to whether this is indeed standard practice. It's hard to know what established practice is here, especially since most of the categories I looked at did not have the building categories, and the higher-level categories for NRHP and CHL don't have them, either.

So tell me: do these categories go under building categories for convenience, even though they contain things other than buildings? Thanks in advance for your input. --Auntof6 (talk) 11:26, 10 October 2014 (UTC)

NRHP numbers cover "places" rather than "buildings". There are examples of historic districts and sites (e.g. large military sites with many buildings) under a single NRHP number. If a category is to use the NRHP template, it should uniquely cover the place intended, which means that though many NRHP numbers can match a single building and a single category, some cases may require that only a top parent category to many buildings is identified this way.

P.S. due to issues of this type, I have suspended my "intelligent NRHP categorization" which was generating Commons:Batch uploading/Library of Congress/HABS. I am not currently planning on returning to it due to these issues of inconsistency, along with other tricky issues of n-th parent-child interrelationships on the categories; which are probably not worth my unpaid volunteer programmer time to handle compared to other projects I could focus on. --Fæ (talk) 11:34, 10 October 2014 (UTC)

I'm with Auntof6 on this. Many listings on the NRHP are not buildings. It would be fine to introduce a layer of "Buildings on the National Register of Historic Places..." categories, much as we already have categories like Category:Apartment buildings on the National Register of Historic Places in Oregon. But if someone does this, please take it on for the whole U.S., so we don't end up with this layer for some states and not for others. - Jmabel ! talk 00:17, 11 October 2014 (UTC)

I also agree with Auntof6 on the same point that not all NRHP listings are of buildings. We do already have Category:Buildings and structures on the National Register of Historic Places by state. --Mjrmtg (talk) 15:30, 12 October 2014 (UTC)

Thanks, Mjrmtg. The particular discussion we had concerned counties rather than states, but the same idea applies. --Auntof6 (talk) 23:47, 12 October 2014 (UTC)

Thanks, Jmabel. I'd be willing to work on that. Of course, it might take a while to get all the states and territories done, and some might not have entries to support a "building" category. I was hoping to get Look2See1's opinion here so that all viewpoints were represented, but maybe we'll still get input from other who share his/her viewpoint. --Auntof6 (talk) 23:47, 12 October 2014 (UTC)

Freedom of Expression book cover help

• en:File:2005 Freedom of Expression by Kembrew McLeod.jpg

Does this image qualify for the license tag {{PD-ineligible}}, and if so, why? Does it have to do that it's only words and text and no images? And if so, can it be moved here to Commons from en.wikipedia ?

Thank you for the explanation, this is a new thing to me about tagging book covers on en.wikipedia with any license other than the "fair use rationale" thingy. -- Cirt (talk) 04:35, 11 October 2014 (UTC)

• Looks PD-ineligible to me. - Jmabel ! talk 06:31, 11 October 2014 (UTC)
  • Why? -- Cirt (talk) 07:28, 11 October 2014 (UTC)
    • Straight-out typography of text is never enough to get copyright on a visual basis, and I don't see any textual content there that would rise to the level of being copyrightable. Do you? - Jmabel ! talk 17:28, 11 October 2014 (UTC)
      • Okay, what about this book cover ?? -- Cirt (talk) 18:51, 11 October 2014 (UTC)

Cirt -- Don't know why you would want to transfer such a tiny and low-quality image, but basic font-character shapes in raster graphics format are always out of copyright in the United States ({{PD-font}}), and if the Best Western logo is uncopyrightable in the United States, then this overall book cover is uncopyrightable in the United States... AnonMoos (talk) 15:48, 12 October 2014 (UTC)

@AnonMoos: , feel free to upload a higher quality image over that one at File:2005 Freedom of Expression by Kembrew McLeod.jpg. But what about this book cover ?? -- Cirt (talk) 15:52, 12 October 2014 (UTC)

Ditto. In the U.S., a piece composed of straightforward typography and simple geometric shapes is never eligible for copyright. - Jmabel ! talk 17:09, 12 October 2014 (UTC)

Okay, great, thanks very much!!! :) -- Cirt (talk) 22:53, 12 October 2014 (UTC)

October 12

Deletion requests for dummies

Hi,

I noted that many deletion requests are not done properly (uploader not informed, etc.), so I started a Deletion requests for dummies: Commons:Guidelines for tagging copyright violations. Please help with suggestions, style, and proofreading. Thanks, Yann (talk) 21:24, 12 October 2014 (UTC)

October 13

{{Information}} display error

How on EARTH did this happen? https://commons.wikimedia.org/w/index.php?title=File:Mathew_Brady_-_Franklin_Pierce.jpg&oldid=134816470 - 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. --Fæ (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 (talk • contribs) 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)

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

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. [6]) 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)

Copyright status of a photo of a public domain painting

@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: Template:OTRS ticket--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 Slowking4 ♡ Farmbrough'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

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

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 https://en.wikipedia.org/wiki/Wikipedia:Bug_reports_and_feature_requests. --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 ?

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. http://fr.wikipedia.org/wiki/Discussion:67P/Tchourioumov-Guerassimenko

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

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)

Monobook TWINKLE help

This error text:

Error: https://commons.wikimedia.org/w/index.php?title=User:Kanonkas/twinklefluff.js&action=raw&ctype=text/javascript 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

Suspend the Upload Wizard

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)

•  Oppose on the grounds that UploadWizard really does make uploading easier. -mattbuck (Talk) 20:22, 6 October 2014 (UTC)
•  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. Slowking4 ♡ Farmbrough's revenge 12:20, 7 October 2014 (UTC)
•  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)

•  Oppose, but  Support an "Upload Wizard Wishlist for improvement".  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. […]

— LX, in: in 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)

 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)

 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)

•  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)

•  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)

•  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)
•  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)
•  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)

•  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)

•  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)

•  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)
•  Oppose Its more easy upload 30 images in same time --Wilfredo R. Rodríguez H. (talk) 17:25, 16 October 2014 (UTC)

October 08

Creation of derivative versions of videos

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

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

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.

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. --Fæ (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. --Fæ (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

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

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

Restrict overwriting of files?

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. --Fæ (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 . 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). --Fæ (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. --Fæ (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

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)

 1 An overwrites special page sounds like a useful improvement to page patrol tools.

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. --Fæ (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. --Fæ (talk) 01:26, 17 October 2014 (UTC)

Test query of changed images in Wellcome uploads

Test query of all changed images during the last 10 minutes of uploads on October 16th 2014.

Here's an attempt of doing (enwiki) BLP images:

List of images recently overwritten that are used on a BLP page

MariaDB [enwiki_p]> select log_title as image, time_format(log_timestamp, "%Y-%m-%dT%H:%i:%s" ) as timestamp, count(*) as "numb of BLP", IF( abs( img_timestamp - log_timestamp ) < 8, "top", "now replaced" ) as top from commonswiki_p.logging_logindex inner join commonswiki_p.globalimagelinks on log_title = gil_to and gil_wiki = 'enwiki' left outer join commonswiki_p.image on img_name = log_title inner join enwiki_p.categorylinks on gil_page = cl_from and cl_to in ( 'Living_people', 'Possibly_living_people', '2014_deaths', '2013_deaths', '2012_deaths' ) where log_type = 'upload' and log_action = 'overwrite' and log_timestamp > '20141015000000' group by log_timestamp, log_title order by log_timestamp desc limit 30; +-------------------------------------+---------------------+-------------+--------------+ | image | timestamp | numb of BLP | top | +-------------------------------------+---------------------+-------------+--------------+ | Civil_Disturbance_Ribbon.JPG | 2014-10-17T00:56:47 | 1 | top | | Commendation_Medal1.JPG | 2014-10-17T00:43:44 | 1 | top | | Active_Duty_for_Training_Ribbon.JPG | 2014-10-17T00:35:48 | 1 | top | | Disaster_Relief_Ribbon.JPG | 2014-10-17T00:33:03 | 1 | top | | War_Service_Ribbon.JPG | 2014-10-17T00:28:34 | 2 | top | | Exemplary_Conduct_Medal.JPG | 2014-10-17T00:26:00 | 1 | top | | Service_Medal1.JPG | 2014-10-17T00:23:12 | 1 | top | | Ranger_Tab.svg | 2014-10-16T22:00:55 | 5 | top | | Ranger_Tab.svg | 2014-10-16T21:36:30 | 5 | now replaced | | Sts-60-patch.png | 2014-10-16T21:01:58 | 6 | top | | Johan_Neeskens_1974.jpg | 2014-10-16T20:09:40 | 1 | top | | Roopa_Revathi.jpg | 2014-10-16T18:08:24 | 1 | top | | Sts-53-patch.png | 2014-10-16T16:56:27 | 4 | top | | Niyaz_Ahmed_AS1.jpg | 2014-10-16T15:57:01 | 1 | top | | Sts-59-patch.png | 2014-10-16T15:27:21 | 6 | top | | Daniel_Leclercq.jpg | 2014-10-16T12:02:54 | 1 | top | | Natalie_Portman_Thor_2_cropped.png | 2014-10-16T10:58:04 | 1 | top | | Wouter_Sybrandy.jpg | 2014-10-16T03:29:15 | 1 | top | | Flag_of_Ireland.svg | 2014-10-16T00:31:49 | 1948 | top | | Coa_Hungary_Town_Debrecen.svg | 2014-10-16T00:30:55 | 1 | top | | Zoe_Quinn_Car_2014.jpg | 2014-10-15T21:36:38 | 1 | top | | Yeon_Woo_Jin_-_2013.jpg | 2014-10-15T21:31:29 | 1 | top | | Zoe_Quinn_Car_2014.jpg | 2014-10-15T21:26:34 | 1 | now replaced | | Sts-41-d-patch.png | 2014-10-15T21:11:09 | 5 | top | | Dave_Schultz_hockey.JPG | 2014-10-15T19:17:36 | 1 | top | | Dave_Schultz_hockey.JPG | 2014-10-15T19:16:55 | 1 | now replaced | | Flag_of_Mexico_(1934-1968).svg | 2014-10-15T18:28:29 | 72 | top | | Orion_Head_to_Toe.jpg | 2014-10-15T16:23:28 | 1 | top | | BedeBD-4C-FORD.JPG | 2014-10-15T15:37:10 | 1 | top | | Chris_Huhne_MP_crop.jpg | 2014-10-15T15:35:14 | 1 | top | +-------------------------------------+---------------------+-------------+--------------+ 30 rows in set (20.59 sec)

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... --Fæ (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)

overwritten BLP images by people < 500 edits

MariaDB [enwiki_p]> select log_title as image, time_format(log_timestamp, "%Y-%m-%dT%H:%i:%s" ) as timestamp, count(*) as "numb BLPs", IF( abs( img_timestamp - log_timestamp ) < 8, "top", "now replaced" ) as top from commonswiki_p.logging_logindex inner join commonswiki_p.globalimagelinks on log_title = gil_to and gil_wiki = 'enwiki' left outer join commonswiki_p.image on img_name = log_title inner join enwiki_p.categorylinks on gil_page = cl_from and cl_to in ( 'Living_people', 'Possibly_living_people', '2014_deaths', '2013_deaths', '2012_deaths' ) inner join commonswiki_p.user on log_user = user_id and user_editcount < 500 where log_type = 'upload' and log_action = 'overwrite' and log_timestamp > '20141014000000' group by log_timestamp, log_title order by log_timestamp desc limit 30; +------------------------------------------------------------------+---------------------+-----------+--------------+ | image | timestamp | numb BLPs | top | +------------------------------------------------------------------+---------------------+-----------+--------------+ | Roopa_Revathi.jpg | 2014-10-16T18:08:24 | 1 | top | | Niyaz_Ahmed_AS1.jpg | 2014-10-16T15:57:01 | 1 | top | | Natalie_Portman_Thor_2_cropped.png | 2014-10-16T10:58:04 | 1 | top | | Wouter_Sybrandy.jpg | 2014-10-16T03:29:15 | 1 | top | | Zoe_Quinn_Car_2014.jpg | 2014-10-15T21:36:38 | 1 | top | | Yeon_Woo_Jin_-_2013.jpg | 2014-10-15T21:31:29 | 1 | top | | Zoe_Quinn_Car_2014.jpg | 2014-10-15T21:26:34 | 1 | now replaced | | Orion_Head_to_Toe.jpg | 2014-10-15T16:23:28 | 1 | top | | Chris_Huhne_MP_crop.jpg | 2014-10-15T15:35:14 | 1 | top | | Flag_of_the_Basque_Country.svg | 2014-10-15T04:20:52 | 54 | top | | Martin_Ødegaard.JPG | 2014-10-15T03:14:59 | 1 | top | | David_Cameron_official.jpg | 2014-10-15T00:24:28 | 1 | top | | Ed_Miliband_2.jpg | 2014-10-15T00:20:11 | 4 | top | | LG전자,_새로워진_‘소녀시대_쿠키폰’_출시-2.JPG | 2014-10-14T23:55:03 | 1 | top | | ReasonFest_2013.jpg | 2014-10-14T23:32:36 | 1 | top | | Grant_Hutchinson_Swifts.jpg | 2014-10-14T23:28:22 | 1 | top | | PaulSmartLE1000.jpg | 2014-10-14T19:19:57 | 2 | top | | Goldsmiths_Main_Building.jpg | 2014-10-14T16:53:20 | 2 | top | | Maria_Sergejeva.jpg | 2014-10-14T16:16:15 | 1 | top | | Jennifer_Lawrence_at_the_83rd_Academy_Awards_crop.jpg | 2014-10-14T01:49:05 | 1 | now replaced | | Jennifer_Lawrence_at_the_83rd_Academy_Awards_crop.jpg | 2014-10-14T01:49:00 | 1 | now replaced | | Jennifer_Lawrence_at_the_83rd_Academy_Awards_crop.jpg | 2014-10-14T01:48:48 | 1 | now replaced | | Jennifer_Lawrence_at_the_83rd_Academy_Awards_crop.jpg | 2014-10-14T01:47:05 | 1 | now replaced | | Jennifer_Lawrence_at_the_83rd_Academy_Awards_crop.jpg | 2014-10-14T01:29:02 | 1 | now replaced | | Jennifer_Lawrence_at_the_83rd_Academy_Awards_crop.jpg | 2014-10-14T01:28:04 | 1 | now replaced | | Jennifer_Lawrence_at_the_83rd_Academy_Awards_crop.jpg | 2014-10-14T01:25:53 | 1 | now replaced | | Jennifer_Lawrence_at_the_83rd_Academy_Awards_crop.jpg | 2014-10-14T01:24:25 | 1 | now replaced | | Jennifer_Lawrence_at_the_83rd_Academy_Awards_crop.jpg | 2014-10-14T01:18:30 | 1 | now replaced | | Jennifer_Lawrence_at_the_83rd_Academy_Awards_crop.jpg | 2014-10-14T01:10:43 | 1 | now replaced | | Jennifer_Lawrence_at_the_83rd_Academy_Awards_crop.jpg | 2014-10-14T00:53:18 | 1 | now replaced | +------------------------------------------------------------------+---------------------+-----------+--------------+ 30 rows in set (2.51 sec)

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)

Overwrites, not original uploader, BLP images, <100 commons edits, <200 enwiki edits

MariaDB [enwiki_p]> select log_title as image, time_format(log_timestamp, "%Y-%m-%dT%H:%i:%s" ) as timestamp, count(*) as "numb BLPs", IF( abs( img_timestamp - log_timestamp ) < 8, "top", "now replaced" ) as top from commonswiki_p.logging_logindex inner join commonswiki_p.globalimagelinks on log_title = gil_to and gil_wiki = 'enwiki' left outer join commonswiki_p.image on img_name = log_title inner join enwiki_p.categorylinks on gil_page = cl_from and cl_to in ( 'Living_people', 'Possibly_living_people', '2014_deaths', '2013_deaths', '2012_deaths' ) inner join commonswiki_p.user on log_user = user_id and user_editcount < 100 left outer join enwiki_p.user u2 on log_user_text = u2.user_name left outer join commonswiki_p.oldimage on img_name = oi_name where log_type = 'upload' and log_action = 'overwrite' and log_timestamp > '20141000000000' and oi_user != img_user and ( u2.user_editcount < 200 or u2.user_editcount is NULL ) group by log_timestamp, log_title, oi_timestamp having oi_timestamp = MIN(oi_timestamp) order by log_timestamp desc limit 60; +-------------------------------------------------------+---------------------+-----------+--------------+ | image | timestamp | numb BLPs | top | +-------------------------------------------------------+---------------------+-----------+--------------+ | Zoe_Quinn_Car_2014.jpg | 2014-10-15T21:26:34 | 1 | now replaced | | Jennifer_Lawrence_at_the_83rd_Academy_Awards_crop.jpg | 2014-10-14T01:49:05 | 1 | now replaced | | Jennifer_Lawrence_at_the_83rd_Academy_Awards_crop.jpg | 2014-10-14T01:49:05 | 1 | now replaced | | Jennifer_Lawrence_at_the_83rd_Academy_Awards_crop.jpg | 2014-10-14T01:49:05 | 1 | now replaced | | Jennifer_Lawrence_at_the_83rd_Academy_Awards_crop.jpg | 2014-10-14T01:49:00 | 1 | now replaced | | Jennifer_Lawrence_at_the_83rd_Academy_Awards_crop.jpg | 2014-10-14T01:49:00 | 1 | now replaced | | Jennifer_Lawrence_at_the_83rd_Academy_Awards_crop.jpg | 2014-10-14T01:49:00 | 1 | now replaced | | Jennifer_Lawrence_at_the_83rd_Academy_Awards_crop.jpg | 2014-10-14T01:48:48 | 1 | now replaced | | Jennifer_Lawrence_at_the_83rd_Academy_Awards_crop.jpg | 2014-10-14T01:48:48 | 1 | now replaced | | Jennifer_Lawrence_at_the_83rd_Academy_Awards_crop.jpg | 2014-10-14T01:48:48 | 1 | now replaced | | Jennifer_Lawrence_at_the_83rd_Academy_Awards_crop.jpg | 2014-10-14T01:47:05 | 1 | now replaced | | Jennifer_Lawrence_at_the_83rd_Academy_Awards_crop.jpg | 2014-10-14T01:47:05 | 1 | now replaced | | Jennifer_Lawrence_at_the_83rd_Academy_Awards_crop.jpg | 2014-10-14T01:47:05 | 1 | now replaced | | Jennifer_Lawrence_at_the_83rd_Academy_Awards_crop.jpg | 2014-10-14T01:28:04 | 1 | now replaced | | Jennifer_Lawrence_at_the_83rd_Academy_Awards_crop.jpg | 2014-10-14T01:28:04 | 1 | now replaced | | Jennifer_Lawrence_at_the_83rd_Academy_Awards_crop.jpg | 2014-10-14T01:28:04 | 1 | now replaced | | Jennifer_Lawrence_at_the_83rd_Academy_Awards_crop.jpg | 2014-10-14T01:24:25 | 1 | now replaced | | Jennifer_Lawrence_at_the_83rd_Academy_Awards_crop.jpg | 2014-10-14T01:24:25 | 1 | now replaced | | Jennifer_Lawrence_at_the_83rd_Academy_Awards_crop.jpg | 2014-10-14T01:24:25 | 1 | now replaced | | Jennifer_Lawrence_at_the_83rd_Academy_Awards_crop.jpg | 2014-10-14T01:10:43 | 1 | now replaced | | Jennifer_Lawrence_at_the_83rd_Academy_Awards_crop.jpg | 2014-10-14T01:10:43 | 1 | now replaced | | Jennifer_Lawrence_at_the_83rd_Academy_Awards_crop.jpg | 2014-10-14T01:10:43 | 1 | now replaced | | Jennifer_Lawrence_at_the_83rd_Academy_Awards_crop.jpg | 2014-10-14T00:53:18 | 1 | now replaced | | Jennifer_Lawrence_at_the_83rd_Academy_Awards_crop.jpg | 2014-10-14T00:53:18 | 1 | now replaced | | Jennifer_Lawrence_at_the_83rd_Academy_Awards_crop.jpg | 2014-10-14T00:53:18 | 1 | now replaced | | Atdhetar_Cakaj.jpg | 2014-10-12T17:54:35 | 1 | top | | Angela_Eiter.jpg | 2014-10-10T12:26:22 | 1 | top | | Flag_of_Austria-Hungary_(1869-1918).svg | 2014-10-09T21:10:29 | 1 | now replaced | | Flag_of_Austria-Hungary_(1869-1918).svg | 2014-10-09T21:10:29 | 1 | now replaced | | Flag_of_Austria-Hungary_(1869-1918).svg | 2014-10-09T21:10:29 | 1 | now replaced | | Flag_of_Austria-Hungary_(1869-1918).svg | 2014-10-09T21:10:29 | 1 | now replaced | | Flag_of_Austria-Hungary_(1869-1918).svg | 2014-10-09T21:10:29 | 1 | now replaced | | Flag_of_Austria-Hungary_(1869-1918).svg | 2014-10-09T21:10:29 | 1 | now replaced | | Ashraf_Ghani_Ahmadzai_July_2014_(cropped).jpg | 2014-10-09T08:27:51 | 1 | now replaced | | Ashraf_Ghani_Ahmadzai_July_2014_(cropped).jpg | 2014-10-09T08:20:44 | 1 | now replaced | | Caroline_corr.jpg | 2014-10-07T14:18:33 | 1 | top | | Caroline_corr.jpg | 2014-10-07T14:18:33 | 1 | top | | Caroline_corr.jpg | 2014-10-07T14:18:33 | 1 | top | | Céline_Dion_2012.jpg | 2014-10-05T15:56:52 | 1 | now replaced | | Céline_Dion_René_Angelil_2012.jpg | 2014-10-05T15:34:37 | 1 | now replaced | | Céline_Dion_René_Angelil_2012.jpg | 2014-10-05T15:34:37 | 1 | now replaced | | Celine_Dion_Concert_Singing_Taking_Chances_2008.jpg | 2014-10-05T15:27:51 | 1 | now replaced | | Celine_Dion_Concert_Singing_Taking_Chances_2008.jpg | 2014-10-05T15:27:51 | 1 | now replaced | | Celine_Dion_Concert_Singing_Taking_Chances_2008.jpg | 2014-10-05T15:27:51 | 1 | now replaced | | Céline_Dion_1986.jpg | 2014-10-05T15:22:21 | 1 | top | | Céline_Dion_1986.jpg | 2014-10-05T15:19:14 | 1 | now replaced | | Céline_Dion_2012.jpg | 2014-10-05T15:13:51 | 1 | now replaced | | Céline_Dion_2012.jpg | 2014-10-05T15:10:36 | 1 | now replaced | | Céline_Dion_2012.jpg | 2014-10-05T15:10:35 | 1 | now replaced | | Céline_Dion_2012.jpg | 2014-10-05T15:10:30 | 1 | now replaced | | TexasHoFAwards09LukeWilson.jpg | 2014-10-02T20:06:07 | 1 | now replaced | | TexasHoFAwards09LukeWilson.jpg | 2014-10-02T20:06:07 | 1 | now replaced | | Tony_Salantri.jpg | 2014-10-02T17:02:13 | 1 | top | | Fiona_Apple_2012.png | 2014-10-02T15:50:59 | 1 | top | +-------------------------------------------------------+---------------------+-----------+--------------+ 54 rows in set (30.80 sec)

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). --Fæ (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 --Fæ (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. --Fæ (talk) 19:44, 17 October 2014 (UTC)

October 15

Fictional historic flags

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

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)

Introduction to Wikidata

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

Insignia copyright status questions

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)

Using images on an external website

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

Watchlist broken?

Tracked in Phabricator
Task T74330

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)

Tracked in Phabricator
Task T74340

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)

Resolved

WTF is going on with the panes (monobook)

Tracked in Phabricator
Task T74345

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)

Tracked in Phabricator
Task T757

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

Photographs in a scientific journal

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[7] of the CC-SA..-licensed work.[8]. 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, but NC (non-commercial) licenses are not used (= not permitted) on commons. –Be..anyone (talk) 15:27, 22 October 2014 (UTC)

Many thanks!

Wikidata phase 2

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

Upload Wizard problems

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 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

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 --Fæ (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 [9]). 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», Fæ? 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. --Fæ (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. -- 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

Tracked in Phabricator
Task T74429

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)

ResolvedFix deployed

Is there a problem with video upload?

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

HotCat issue

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

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)

promoting Commons:Upload tools at Special:UploadWizard

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

Incorrect translation

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)

internetarchivebookimages

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

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

Hello.

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

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

Looks like it may be easier to download them directly from NASA … --El Grafo (talk) 08:41, 25 October 2014 (UTC)

Massive copyright violation by Flick User Ashur Rikah

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:

• Flickr copyvio 1 / my original photo 1
• Flickr copyvio 2 / my original photo 2
• Flickr copyvio 3 / my original photo 3

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 [10]. 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)
      • If contacting the violator fails, issue a "DMCA Take Down" notice (for your own images only) to Yahoo. You can do this since they are violating the license's conditions, therefore the license is terminated (in the full code it is located at section 7) and you've had no response from the violator. Your moral rights are also being violated, which is recognised in some countries (such as Australia, UK, Canada [US is rather interesting, since it is limited and only applies to "visual arts" though the Visual Artists Rights Act]), since they are fraudulently taking credit for your work. Bidgee (talk) 12:14, 25 October 2014 (UTC)

Flickr user has been added to our Blacklist so images don't get uploaded with false authorship claims. --Denniss (talk) 07:35, 25 October 2014 (UTC)

Facebook using the smallest thumbnail from Commons for preview

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 ("http://commons.wikimedia.org/wiki/File:Tight_corners_%2814656940745%29.jpg", for the “status” update post in the example screenshot, above). 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 image link is pasted instead ("http://upload.wikimedia.org/wikipedia/commons/e/e7/Tight_corners_%2814656940745%29.jpg", for the comment in the example screenshot, below), 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)

A backlink is created, yes — indeed this happens when an url to Commons is inserted in a fb status update or comment. -- Tuválkin ✉ 12:33, 25 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)

Those two arrows only show up when an remote url is posted in the fb “status” editbox, not in an fb comment editbox, and even so not always (I think it depends on connection timeouts and memory availability in the client); even when it appears, it shows the half-a-dozen thumbnails of the file in question («this preview», several «Other resolutions», and «Original file») in a small thumbnail swatch itself, so they all look the same and only the most aware will be able to pre-select a good quality version; the smallest thumbnail has been the one chosen by default for me these last couple weeks (that’s why I brought up the matter here).

It seems that this issue is more complicated, as different people report different “user experiences”. Some consultation with fb-people might be necessary to make this work in the best possible way (simplest for the user and yielding best quality) — that would justify some expense (although still way under 4600 €…)

-- Tuválkin ✉ 12:33, 25 October 2014 (UTC)

Time zones of Europe

Brateevsky has re-uploaded File:Time zones of Europe.svg with a new version, anticipating Russia's switch 1 hour backward tonight. However, the templates using it, like {{Time zones of Europe}}, became out of sync with the image. I have updated the en, de, fr, it, es and pt versions, but I don't feel so sure with other languages. If anyone wants to proceed, that'll be really good. Of course, the cognates of {{Time zones of Russia}} should also be updated, but as yet it's not 100% clear how to label the time zones. And the articles should also be updated. But that would be a long story... YLSS (talk) 16:28, 25 October 2014 (UTC)

YLSS, ok, but what's the reason to mention me? I thought something is wrong, f.e. colors. :) Of course, thanks many Wikipedias to User:YLSS, but I think it should be a care of English, German, French and others versions of Wikipedia to update information by users who edit these Wikipedias on a regular basis. When I updating the image, I think about the subsequent updating templates only in Russian-language Wikipedia. Of course, if there are some questions or problems about changing time in Russia, you can write on my talk page on Commons. I don't understand the aim of writing the previous message, maybe to accent the users' attention to much work need to do in different versions of Wikipedia due to changing time in big country, which is in Europe and Asia... --Brateevsky {talk} 17:05, 25 October 2014 (UTC)

Just informing the users of other Wikipedias about the situation, and preventing any questions. Changing a file at Commons is not as noticeable as it should be, so there's always this problem of de-synchronisation. WRT pinging you: well, that was just a hint for you that you made a potentially problematic edit... No, of course, great thanks for re-uploading that file! (Finally, it looks OK after three years of craziness!) But IMHO if you edit a file at Commons, you should think not only about ru.wp, but about others as well... YLSS (talk) 17:19, 25 October 2014 (UTC)

I find some charts that have Wikipedia legends that say that they cover "1980-2007" even though long ago the chart had been updated to -2008, 2009, 2010, 2011, 2012, 2013, and now 2014. A handy trick to avoid that is to use {{CURRENTYEAR}} so that the only out of sync that occurs is for the period of the new year before the chart is updated. This is particularly handy for charts that are used on a large number of wikis and are updated frequently. Delphi234 (talk) 20:06, 25 October 2014 (UTC)

Global deleted image review

More than 6 years ago a consensus was reached that commons administrators needed an ability to view deleted images on other projects. Due to the recent software changes it is now possible to give users an ability to view deleted revisions of files separately from other namespaces (See m:Wikimedia_Forum#Implement_Global_deleted_image_review). There is currently a discussion of implementation of this new userrirght. Ruslik (talk) 19:29, 25 October 2014 (UTC)

October 26

Licensed images

What's the deal with licensed images? By these I mean the (typically high resolution) images museums make available for purchase at varying prices depending on the degree you wish to publish them. Purchasing one for publication on Commons would certainly cost you an arm and a leg, yet I've noticed quite a few leaking onto Commons which I'm prepared to wager haven't been paid for fairly.

I understand it's not a copyright issue, but the uploader is clearly at risk of a lawsuit is he not? Would Wikipedia support an uploader in that case? I can't imagine it would.

I ask because one of the English Wikipedia's most prolific editors, an administrator in charge of a high profile project involving images on the English Wikipedia, has recently done just that to a beautiful high resolution image from the Mauritshuis museum in The Hague. He was plainly aware of what he was doing because the mid-resolution image had already been uploaded and the editor copied over the notes from that upload (incidentally giving the false impression that the source was the museum page - but it wasn't - they aren't available as Zoomify images or similar - you have to fill out a form and pay good money for them). When I taxed him on the question (earning myself an indefinite block for my troubles by the way ), he said he was under no contractual obligation since he hadn't himself purchased it. Perhaps he's implying it was available in his department for research purposes (he's an academic) and he just thought to upload it to Commons as a service to our community. Can that really be justified?

I don't think this is merely a Coatzee type issue involving in essence what is acceptable special processing when it comes to downloading. It's of a different nature and I should like to draw the community's attention to the issue. It's such a shame because the Maurtitshuis made a big effort at its revamped website to make their beautiful images available. Marinka van Dam (talk) 15:37, 25 October 2014 (UTC)

Could you please specify the image/filename to which are refering. --Túrelio (talk) 15:42, 25 October 2014 (UTC)

The high resolution licensed version is File:Meisje met de parel.jpg. The medium resolution publicly available download version uploaded earlier is File:Johannes Vermeer -Girl with a Pearl Earring - Mauritshuis 670.jpg. The discussion I refer to (me now heavily struck through) is here. Marinka van Dam (talk) 15:52, 25 October 2014 (UTC)

If I understand you correctly, the current source-entry for the high-res version is bogus as the file isn't available at that location, right? By the way, the link to :en page seems to be wrong or the target page has ben deleted. --Túrelio (talk) 16:09, 25 October 2014 (UTC)

That's correct, with this proviso that when we say "isn't available" we mean is not downloadable: you have to make a purchase - the link is this, or if you go to the museum page linked in the file description and choose the fifth icon down for uploading you are given two choices "downloaden privégebruik" (it always amuses me how the Dutch welcome loan words - you wouldn't see that in France) i.e. download for private use, which gives you the medium resolution file, or " Aanvraag beeld (commercieel)" i.e. "request an image for commercial use", which brings you to the page I linked before. I should make the caveat that I'm assuming the high resolution the Wikipedia administrator uploaded is the commercial image. He hasn't denied it, only that it wasn't a purchase (i.e. by, so I assume, him). I shall check that with the museum directly Monday. As for the discussion that's still there permalinked here.

Incidentally this is not the only high resolution licensed image that has been uploaded to Commons from the Mauritshuis. I can't get the details right now but I gather there are several that have been located, and in some cases the files' color balance were adjusted to add insult to injury (it's common for uploaders to warm images to their personal satisfaction).

What I'm seeking here is guidance on the principle of uploading such images. It's common ground that the image isn't copyright, but can Wikipedia allow it knowing that a contractual obligation has unquestionably been broken, whether by the uploader or the original purchaser for being negligent in his duty of care? As Yann points out below, no museum that runs this kind of service (the British Museum being a notable example in the UK) would license this image for reproduction on Commons. Marinka van Dam (talk) 18:26, 25 October 2014 (UTC)

The Wikimedia Foundation has no responsibility to police contracts that it's not a party to, especially contracts that it doesn't know the text of or even necessarily that they exist.--Prosfilaes (talk) 19:44, 25 October 2014 (UTC)

Well, yes, that's exactly the issue I want to see debated. Marinka van Dam (talk) 22:10, 25 October 2014 (UTC)

O.k., that means the current source-entry for the high-res version is invalid. I've requested information from the uploader.

Needless to say that, if the image is indeed available only under a paid-for-license, such a behaviour isn't in the best interest of Commons, as it may diminish the willingness of Mauritshuis and other museums to future cooperation with Wikipedia/Commons. --Túrelio (talk) 21:20, 25 October 2014 (UTC)

The zoom function given as source goes from 2562x3000 (852KB) up to 5124x6000 (6.31MB). –Be..anyone (talk) 06:18, 27 October 2014 (UTC)

Hi,

First museum images are not a issue, as most works of art in the domain public could be photographed by a way or another by a contributor. It would probably be more useful for famous personalities. Then if the work of art is not in the public domain, there is no point to get an image.

But even if you pay, an agency will never let you relicense an image under a free license. It would ruin their business. Regards, Yann (talk) 15:46, 25 October 2014 (UTC)

Well, exactly. I mean consider the deal Commons has with the Tropenmuseum in Amsterdam (or Fae's marathon LACMA effort to give another example, such a useful repository that). Are such deals more likely when editors behave like this? By the way I'm good for loads of input on Indonesia textiles at the English Wikipdia if some administrator is brave enough to unblock me Promise tio begave most of the time. El Classico beckons, back later Marinka van Dam (talk) 15:58, 25 October 2014 (UTC)

Note w:en:Wikipedia:Sockpuppet_investigations/Coat_of_Many_Colours, which makes the case that Marinka is a Coat of Many Colours sock, which would make her a sock here, too.--Prosfilaes (talk) 19:54, 25 October 2014 (UTC)

Oh for goodness sake P, stop being so city-hall. I am absolutely not a sock of Coat. See my talk-page. Their are people banned for perpetuity from English Wikipedia who make splendid contributions here. The ever faithful and very worthy Fae being an example that comes immediately to mind. Marinka van Dam (talk) 22:10, 25 October 2014 (UTC)

Marinka van Dam is a researcher at the Victoria and Albert Museum. This "Marinka van Dam" is a sockpuppet of Coat. Bad taste choice of user name. Xanthomelanoussprog (talk) 10:14, 26 October 2014 (UTC)

I've blocked the Marinka acct, and left a message telling User:Coat of Many Colours to use that acct, since it isn't blocked here, etc. INeverCry 10:55, 26 October 2014 (UTC)

Is PubMed Central locking up CC-licensed images, or am I just confused?

I just had a hell of a time trying to smuggle an image out of a near identical twin of the MediaViewer at w:NCBI at this location (article here, my upload at File:Phylogenetic analyses of HRV and HEV.jpg). Like ours did, it was at least beyond my ability to find a download link for the full resolution version. I am inclined to read bad motives into this, especially since the page only works with Javascript enabled, which when viewing plain content is the sure sign of a villain anywhere on the Web. Anyway, my upload is proof of principle that it is manually possible to piece together the image from pieces like [11] (as per w:Zoomify, in my vague recollection). Can I get someone else to look - is there a simple way to get the hi-res that I missed? Or do we need to design a tool here that automatically downloads and assembles the jpg out of these bits and pieces? (I suppose they can go to Flash encryption, except theoretically that's against the CC license, isn't it?) The scientists are paying good money to open-license their work, and no one should be allowed to seize it from us with tricks and schemes. Wnt (talk) 19:00, 25 October 2014 (UTC)

@Wnt: Hi, Could you please use the {{Information}} template? Thanks, Yann (talk) 19:13, 25 October 2014 (UTC)

@Yann: I'm not sure, but I think the reason why that template didn't get used was that when I went to upload, there was no option given for CC-by-SA-2.0. ..... unless the file is from Flickr! So I left it at none and spliced in a template afterward. Why Commons has a built in option for licensing from one company but not from the rest of the world is another interesting question! Wnt (talk) 19:43, 25 October 2014 (UTC)

Weird. That never happened to me, even when I set the license manually. You can add it now anyway. ;o) Yann (talk) 19:46, 25 October 2014 (UTC)

@Wnt: Uhm, maybe I've missed something, but why don't you just go to the original journal's website and download the files from there? It's just one click away if you take the doi link above the paper's title. → full resolution of the first figure --El Grafo (talk) 19:24, 25 October 2014 (UTC)

PS: Your image is here, use the link at the bottom of the page to download the original TIF file as it was provided by the authors of the paper. --El Grafo (talk) 19:27, 25 October 2014 (UTC)

That's all well and good, provided that the journal makes it available. The point, though, is that PubMed Central is/was supposed to be a single common archive for papers from all over. If the journal goes out of business, or if it decides to impose the same lockdown on its own image server, it is no longer an option. Thank you for your effort, but I hope you understand why I'm not happy to have a public resource being made intentionally very difficult to use. (I should confirm that the download from your link appears to be the same as what I got by splicing together the images from PMC) Wnt (talk) 19:40, 25 October 2014 (UTC)

Umm, El Grafo's link is 1885x1959 px. Yours is 1,200 × 1,528 (Note that on the website there is both an "original file" and a "high resolution" link. The original file is higher resolution, and also losslessly encoded). Bawolff (talk) 04:25, 26 October 2014 (UTC)

@Bawolff: You looked at a different figure. The comparison is this one, also a jpg and 1200 x 1528. Of course, I have not confirmed that every image on PMC retains the full resolution when delivered in pieces, but this one does. Wnt (talk) 17:17, 26 October 2014 (UTC)

http://www.virologyj.com/content/download/figures/1743-422X-10-305-6.tiff is a tiff that's 1885x1959. Bawolff (talk) 21:48, 26 October 2014 (UTC)

The University of Jordan Community service

Arabic Wikipedia community is at its final stages of negotiations with the University of Jordan. We are now talking about adding a photography tasks that would be considered as community service by the university. Each student should fulfill certain hours per semester doing some kind of work that would reflect back on his/her community. Arabic Wikipedia community suggested that each student should get and upload 50 photos covering different aspects within Jordan.

The photos are to be owned by The University of Jordan, and the idea is to release all this work under a free license. The University of Jordan are taking about the use of their own JU_USE license that only permits non-profit usages, but hopefully we will overcome that in a few days. In the meanwhile I will work on a few templates that will encourage them, it seems colorful templates with BIG-CABS names is charming. I will also create a campaign page to make it easier for the students to upload the photos here.

What I need help in is: A way to figure-out and count images uploaded by each student for each semester, so we can email the results back to the university at the end of each semester as a prof that the students did that part of the C.S.

Keep in mind we are talking about 43000 student. --Tarawneh (talk) 07:10, 26 October 2014 (UTC)

• If they each have an account from which to upload, and we come up with a central page on which to list the relevant accounts, it would be easy for a bot to report on the number of uploads from each account.
• Alternatively, or in addition, it would be nice to have a category (probably driven by a template) that was placed on all of the images for this (that would also allow people to upload images on the same accounts that they don't want counted toward this, especially if they retain their accounts after graduating). Again, it would be easy for a bot to limit its count to images in that category. - Jmabel ! talk 17:44, 26 October 2014 (UTC)

Meta RfCs on two new global groups

Hello all,

There are currently requests for comment open on meta to create two new global groups. The first is a group for members of the OTRS permissions queue, which would not contain any additional user rights. That proposal can be found at m:Requests for comment/Creation of a global OTRS-permissions user group. The second is a group for Wikimedia Commons admins and OTRS agents to view deleted file pages through the 'viewdeletedfile' right on all wikis except those who opt-out. The second proposal can be found at m:Requests for comment/Global file deletion review.

We would like to hear what you think on both proposals. Both are in English; if you wanted to translate them into your native language that would also be appreciated.

It is possible for individual projects to opt-out, so that users in those groups do not have any additional rights on those projects. To do this please start a local discussion, and if there is consensus you can request to opt-out of either or both at m:Stewards' noticeboard.

Thanks and regards, Ajraddatz (talk) 18:04, 26 October 2014 (UTC)

Category:Necropoli dei Monterozzi (Tarquinia)

Hi, Should we rename this category and these subcategories into English? Regards, Yann (talk) 20:08, 26 October 2014 (UTC)

October 27

WLM and countries with no FoP

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)

 Support such a notice because it would reduce the extra work such uploads have created. After deleting several such images, I have temporarily undeleted them so a bot can copy them to Ukrainian Wikipedia as fair use images. From the requesters contributions it appears there are more than a few images needing temporary undeletion. Some of these might have been avoided if uploaders had had a notice about freedom of panorama. Green Giant (talk) 10:25, 25 October 2014 (UTC)

This is just difficult technically. Whatever notice you add, the uploaders (who are mostly newbies) do not read it, and if they do, they do not understand it as they have no idea what FoP means. The upload wizard can be slightly improved but I am afraid this is not going to solve the problem.--Ymblanter (talk) 10:32, 25 October 2014 (UTC)

I recommended to do the same to Ukrainian and Belarusian administrators couple of years ago. At least such warning may reduce level of frustrations by new users. Will be good idea to involve Wikidata to fetch of creation/installation/authors information for particular object so warnings may be much more specific. --EugeneZelenko (talk) 14:39, 25 October 2014 (UTC)

What about making the respective templates smart enough to know internally the FoP status of each country? Then, the user could just add the name of the country and the template would figure out if that particular country has acceptable FoP or not.--Snaevar (talk) 19:40, 26 October 2014 (UTC)

Wiki Loves Monuments is Dunglish (Dutch trying to speak English), it's actually about old buildings. For example in the Netherlands a building or structure generally needs to be at least 50 years old to be even conspired to become a Rijksmonument. So the number of entries which are not old enough and not covered by FoP will probably be low compared to the totals.

When I used to organize WLM, I tried to stick to it's philosophy. In this case you probably want to have some way to prevent a user from uploading these images to prevent the disappointment. If I recall correctly other countries fixed this problem my included this information in their lists. If the building is old enough the list entry includes a link to Commons to upload, if it's not old enough (and not covered by FoP) it doesn't include the link, but a note about the fact that it's not possible to upload an image of this entry. Multichill (talk) 19:54, 27 October 2014 (UTC)

October 25

Pictures in high resolution

Hi, I have a issue about the resolution of a chemical scheme I made. It concerns the file Natuurproducten_biosynthese_bouwstenen.tif, which should be used on the Dutch version of Wikipedia. The original scheme was drawn by me in ChemDrawBio, version 12. Because of its magnitude, it was not possible to save it as a png-file, nor as an svg-file. The current tif-file is the best I can currently get, but I am not pleased with the quality of it, especially concerning its low resolution. Is there someone who can help me or at least has experience in uploading large chemical schemes made in ChemDraw? Thanks in advance. - Capaccio (talk) 12:07, 26 October 2014 (UTC)

• You'll probably want to take this question to Commons:Graphic Lab/Illustration workshop. - Jmabel ! talk 17:46, 26 October 2014 (UTC)
  • The problem has already been solved by a collegue of mine. See Natuurproducten biosynthese bouwstenen in png. - Capaccio (talk) 19:26, 26 October 2014 (UTC)

This section is resolved and can be archived. If you disagree, replace this template with your comment. Jmabel ! talk 15:25, 27 October 2014 (UTC)

I seem to be getting to keep getting discussions whereby nobody really reads the arguments

I put 4 files for renames: The case seems clearcut: In the pictures there is no electric locomotive, mentioned in the file name, visible. Only an electric multiple unit. However the rename suggestion is refused under with the mention: No valid reason stated, see the rename guidelines. The second time I added the numbers out of rename guide lines, but it is refused again by somebody else. I dont understand: If the file text states that: Bombardier electric locomotive at Dijon and it is not in the image. It is clearly rename reason: #3 (Correct misleading names into accurate ones) and also # 5 (Correct obvious errors in file names)

The files are: File:SNCF 27545 Ter Bourgogne, Bombardier electric locomotive at Dijon, France p1.JPG File:SNCF 27545 Ter Bourgogne, Bombardier electric locomotive at Dijon, France p2.JPG File:SNCF 27505 Ter Bourgogne, Bombardier electric locomotive at Dijon, France p1.JPG File:SNCF 27505 Ter Bourgogne, Bombardier electric locomotive at Dijon, France p2.JPG

For those who are not familiar with railways: In File:SNCF 522356 at Dijon, France p1.JPG there is an electric locomotive.

Smiley.toerist (talk) 19:48, 26 October 2014 (UTC)

I have no idea, why the - obviously correct - rename request was removed twice, but I have renamed the files now (by replacing electric locomotive with EMU). --Sebari (talk) 10:30, 27 October 2014 (UTC)

The only slight problem might be that - except for the hardcore railway-fans - near-to-nobody knows what "EMU" means and that soon Category:Emu will be added. SCNR. --Túrelio (talk) 10:40, 27 October 2014 (UTC)

Correct EMU-Cat would be Category:Electric multiple units, motor coaches and railcars. --Túrelio (talk) 10:48, 27 October 2014 (UTC)

The images are already in the correct specific subcategory: Category:SNCF Class Z 27500Smiley.toerist (talk) 10:05, 28 October 2014 (UTC)

search down?

The search function on Commons seems to be down. When searching for a simple string of 2 words, I get reproducibly no results, but the error-message "An error has occurred while searching: Search is currently too busy. Please try again later..". I've never seen that. Any idea what's going on? --Túrelio (talk) 13:37, 27 October 2014 (UTC)

Also on mw:, not limited to c:. No idea what's wrong. –Be..anyone (talk) 13:49, 27 October 2014 (UTC)

Strange. It's perfectly working on meta and on :de and :en Wikipedia. --Túrelio (talk) 13:52, 27 October 2014 (UTC)

Working again. What ever it was, it is gone. --Túrelio (talk) 13:56, 27 October 2014 (UTC)

Still does not work as expected: e.g. some complicated search like [12] gives timeout (An error has occurred while searching: HTTP request timed out.). As catscan does not work at the moment everybody is using search instead, which in turn … --Herzi Pinki (talk) 14:27, 27 October 2014 (UTC)

Bug Report --Herzi Pinki (talk) 17:42, 27 October 2014 (UTC)

got a response: There is an outage on elasticsearch currently. Folks are working on it. --Herzi Pinki (talk) 20:19, 27 October 2014 (UTC)

POTD 31 Oct

In the caption of POTD for 10-31 the name was misspelled (Prysen, correct Pruysen). I corrected all the templates in different languages (except for Chinese) here on Commons. The file itself has the correct description. However, I do not have time to check all 200+ projects using POTD. If someone transferred an incorrect spelling to a project, or if you are active in a Wikipedia and can easily check whether the spelling is correct on that project, I would much appreciate the effort. Thanks.--Ymblanter (talk) 19:10, 27 October 2014 (UTC)

Editing an existing photo in Commons--How to upload to the same location as original

I have edited someone's photo in Commons--How do I upload to the same location as the original so that it adds to and slots in with existing data? And, for my edited file version, should I change the file name? Paul Goggins (talk) 21:09, 27 October 2014 (UTC)

Resolvedanswered on the help desk –Be..anyone (talk) 22:43, 27 October 2014 (UTC)

October 28

Busan Gimhae Light Rail Transit

I have made a trip to South Korea and uploaded a lot of pictures to Category:Busan Gimhae Light Rail Transit. These need complementary categorisation with local knowledge. I will be regularly uploading South Korean pictures.Smiley.toerist (talk) 08:06, 26 October 2014 (UTC)

For local knowledge, you'd better post this at 사랑방, VP for Korean-speaking users. I'll try to have a look this week. — revi_msg 08:43, 26 October 2014 (UTC)

Is this the local Commons village pump? As by many local Commons forums there is little activity. Better to ask in the main Korean language discussion forum.Smiley.toerist (talk) 11:10, 27 October 2014 (UTC)

How to categorise this picture? no local knowledge is needed.Smiley.toerist (talk) 12:28, 27 October 2014 (UTC)

Identifying ships

The three-masted ship (also File:Haven Busan zeilschip 04.JPG) is used for day trips with motor. The rigging is out of use (with fake elements such as sailor puppets in the rigging) and decks where added to load up a lot passengers. It has now an Korean name, but suspect it was a fully functioning sail ship before the conversion to an moving attraction parc. Has anyone any information about its history?Smiley.toerist (talk) 09:34, 30 October 2014 (UTC)

deletion request question

Recently a picture I loaded up years ago was nominated for deletion - by the person depicted - but kept. I myself supported the deletion request. First because the picture is in fact of such (bad) quality that I would not upload it nowadays, second - and even more important for me - because to me it is a question of respect for the people I take pictures of (which are quite a lot) to comply to their wish, if they find one such picture and ask me (which she also did peronally) to delete it.
Now I face the very unpleasant situation, that one - in fact four - picture(s) I made available here are kept although the person depicted and also I, the creator, myself would like to see it/them deleted. I am aware that this complies to the license. On the other hand we would loose nothing of real importance, because none of the four pictures is used in any Wikimedia project.
It is hard to accept somehow, that even as the creator I have to beg and plead to see one/four of my more then 9000 contributions here deleted. It also makes me wonder, if loading up pictures of identifiable people - which is my main activity here - is really a good idea. As much as I enjoy contributing to illustrate biographies and other articles, I definitely do not want to be the one who puts images online, the people depicted find bad and detrimental. It also, in two other cases unrelated to this pictures, already made really interesting people (with Wikipedia biographies in several languages) refuse my question for taking some portraits. So, what can I do? --Tsui (talk) 18:13, 27 October 2014 (UTC)

This is what's known as a "courtesy" deletion -- when we're not required to delete an image due to copyright considerations or basic Commons policies, but we sometimes choose to delete such an image anyway, out of an abundance of good will...

Probably this image was not deleted because no very substantial specific issue was alleged, or appeared when looking at the photograph. She may not like the way the lighting made her make-up look, but Commons is not in any relationship with her which gives her contractual approval rights over such things. A few times in the past, photographs of living people have been deleted in such circumstances when other photographs approved by the person photographed were offered to Commons under suitable licensing terms and uploaded as replacements. AnonMoos (talk) 13:31, 28 October 2014 (UTC)

A very unsatisfactory and aggravating (English is not my native language, not sure if this terms are exactly how native speakers would express it) situation for me. As I wrote above: When providing pictures to Commons first of all I am concerned about the depicted. I do not want to be the one who publishes pictures they do not approve of. I am not a paparazzo. If I come to know that someone I took a photograph of finds it "bad" and "detrimental" I would really prefer to comply and see it deleted. First of all simply out of respect. To me this is a pastime, to them it is about their very own faces, their image in the public and their personality rights. That's something I take very serious. Second it can also become a problem for me (and others) in the activity as a photographer for Wikimedia/Commons/Wikipedia. The more people have to face such problems, the higher the risk that accreditations are refused or people personally state, they do not want to be photographed for our projects (e.g. because they had to face huge troubles, often failed completely, when trying to get a bad picture out of their biography at Wikipedia). That's something I already had to experience, not often, but it always is very unpleasant. And it is a hindrance to our goal of illustrating articles.

Additionaly: The four pictures discussed would be no loss for us, they are not used in any of our projects. You wrote "Commons is not in any relationship with her which gives her contractual approval rights over such things". True. But do we really (want to) treat the people out there we take pictures of and write about with such - as it appears to me - condescendence? Legally the images should be alright. By putting them under GFDL/cc-by-sa I agreed to the license terms. On the other hand Commons is not obliged to host them. We can and may keep such images, but we do not have to do so.

Lastly: Asking her to provide another image of hers with a suitable license, so that maybe some administrator here might be complaisant and delete the old ones, seems to me almost like I'd try to blackmail her somehow. That may sound harsh, but that's how I feel about it. --Tsui (talk) 15:07, 28 October 2014 (UTC)

 Support the deletion. I do not see anything wrong with File:Laura Gosch, Women's World Awards 2009 d.jpg, but I see no need for the image since other images in Category:Laura Gosch are fine too. We currently have no articles on Laura Gosch. I usually support "courtesy" deletions which do not affect existing articles, as I see no need to alienate our contributors for no apparent purpose. --Jarekt (talk) 17:51, 28 October 2014 (UTC)

 Done I've deleted them, but whether or not they stay deleted is another story. @Tsui: Be very careful what you upload. Situations like this aren't all that rare. INeverCry 10:06, 29 October 2014 (UTC)

Thank you, I am really thankful for your help and decision. The images were from 2009, since then my own standards concerning the quality of images have risen considerably - and I more and more started to send pictures to the people depicted, asking for their approval in advance, before uploading them. So in recent years I'm trying my best to avoid situations like this, that are awkward for the people depicted, for me and for the administrators here or at OTRS. --Tsui (talk) 15:16, 29 October 2014 (UTC)

Tsui, the license you used was and still is very clearly irrevocable. The argument on the deletion request was that it was a bad depiction and was detrimental to the subject. Neither you nor the subject explained why it was a bad depiction or detrimental. As far as I could see, the photos were taken in a public place, at a time when she was due to receive an award. There is nothing to indicate that she was being depicted wrongly or that you had invaded her privacy. Your second argument was that the image was not being used on another project but Commons images are used by many people and websites outside Wikimedia. We have no way of knowing how many copies of the photos were viewed, downloaded and otherwise used. However if anyone did download the photos over four years, they are now in an awkward position because the source images are not public anymore and they may not have proof that their copies are legitimately licensed. I'm not going to be antagonistic and restore the photos but please do me a favour and read the license terms carefully before you upload more images. If you really think an image should be deleted after such a length of time, please give a better reason than "subject suddenly decided she didn't like it". Green Giant (talk) 16:24, 29 October 2014 (UTC)

Image files with no image content

Currently there are 14 images in Category:Media without a license: needs history check where the file name exists but they contain no content. Can someone just nuke them? It seems rather a waste of time nominating them for deletion as they appear to never have been uploaded in the first place. Ww2censor (talk) 17:02, 29 October 2014 (UTC)

 Done Unfortunately I do not know of any tools to speed it up, so there is no "nuking". VisualFileChanges does not see those files, AutoWikiBrouwser speed things a bit. Problem with those files is that they are created when inexperienced users are trying to communicate in relation to recently deleted files, and they often contain text in exotic languages. --Jarekt (talk) 17:25, 29 October 2014 (UTC)

Well I see some are tagged as speedy, so that should go it. Thanks Ww2censor (talk) 17:45, 29 October 2014 (UTC)

@Jarekt: The "nuke" tool available for files like this is Help:Gadget-autodel.js. INeverCry 10:50, 30 October 2014 (UTC)

Best promo videos

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 Category:Wikimedia project videos, 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)

The only needle I'm aware of is File:Wikipedia video tutorial-2-Reliability-en.ogv linked on Help:RSS, belonging to a guided tour produced for WikiMedia Deutschland. Professional, but four years old. –Be..anyone (talk) 12:00, 30 October 2014 (UTC)

File:Wikipedia video tutorials making-of (low).ogv about this production could be also interesting (found in another category.) –Be..anyone (talk) 12:11, 30 October 2014 (UTC)

Announce: Campaign to find 10,000 digitised maps in the British Library's online Flickr stream, starting Friday 31 October

The Battle of Cerro de Pasco in the Peruvian War of Independence, 6 December 1820

Map of Preston, as it was in 1774

Aleppo Vilayet, in 1892

Hi! This is to let people know about a campaign to try to find 10,000 digitised maps (and ground plans) 'hidden' in 13,000 books in the set of a million images that the British Library uploaded to Flickr last year.

Once they've been identified, the BL will then run the maps through its Georeferencer crowd-activity (from which we can download the full output). But first the files need to be identified on Flickr, and tagged as maps. More information can be found in this draft article for the en-wiki Signpost, still under development, and this main information page for the campaign. There's also going to be an all-day tagathon session at the British Library in London to launch the effort, to which anyone who can make it is very welcome. (More details here, with registration link).

There is coverage of maps from all over the world, as shown by this plot of 3,000 maps on the globe, that have already been found and georeferenced. (Non-map images in the collection have a similar distribution, and are also well worth browsing.)

Make-or-break for this is whether people can be encouraged to help on the internet.

The sooner we can get the map images found and tagged the better. For one thing, the BL Labs group are having their annual symposium meeting on Monday 3rd November. It would be fantastic, as a demonstration of the power of openness, if the lion's share of the index could have been worked through by that afternoon. Also, more importantly, the BL won't start the next round of its Georeferencing activity until the map-finding has been completed, which is really the key to making the maps findable and useful.

Realistically, we might be able to get about one quarter of the list checked at the event in London. The remainder will depend on people logging in from all over the world.

So I would really appreciate anything anyone can do to help get the word out -- eg perhaps with mentions in the equivalents of the Signpost in other languages. I'm afraid everything is in English so far, but perhaps there is still time to do something about that. The project status page is at c:Commons:British_Library/Mechanical_Curator_collection/map_tag_status. This page has links to all the geographical index pages, with their pink "Untagged maps" templates. These pages will go live at 11:00 UTC on Friday. (Edits to them before then will probably be over-written -- though tags added on Flickr would be okay).

I would be really grateful for any help anyone could give with this over the weekend, or that anyone can encourage others to give. There are about 13,000 books with Flickr pages to look through in total. Even an hour, or half an hour to go through a block of 15 books in the index, will make a difference.

So anything anyone could do to get the word out between now and then -- eg on local wikis, or mailing lists, or any other ways -- would be very very appreciated.

The pages don't go live until 11:00 UTC on Friday. But after that the more people, from all over the world, that could get involved, the better.

Thanks to everybody, Jheald (talk) 22:16, 28 October 2014 (UTC)

To do this one would need a flikr account, which effectively means a yahoo account, amirite? Rich Farmbrough, 16:41 29 October 2014 (GMT).

@Rich Farmbrough: . Yes, that's right. Flickr does (I think) still let people log in with a Google ID, but only (I think) if a Flickr account had previously been linked to that Google ID, which may no longer be possible. Is it a problem, or just something that people need to be aware of ? Jheald (talk) 17:00, 29 October 2014 (UTC)

I think it need to go into the instructions. (Personally I have an antipathy to telling yahoo my date of birth and mobile phone number, and even my gender - it's none of their business, but I wasn't particularly referring to that.) Rich Farmbrough, 17:35 29 October 2014 (GMT).

You're right. I've a couple of things to do first, then I will fix it. Jheald (talk) 19:05, 29 October 2014 (UTC)

It's now the first thing mentioned in the method section of the campaign main status page, and I've also updated other places. Thanks for this catch! Jheald (talk) 21:07, 30 October 2014 (UTC)

October 29

Modify or replace "Copyright by Wikimedia" template?

Although I have alread posted something regarding this matter in the copyright section, I think the general VP has more readers, so I'm asking here: As per a recent Wikimedia blog entry, the Wikimedia logos are now CC-BY-SA 3.0 + (still) trademarked instead of non-free copyrighted material. Yana Welinder, Legal Counsel, says there:

We would really appreciate your help in replacing the {{Copyright by Wikimedia}} templates for all Wikimedia logos on Commons! Each of the Wikimedia logos in every language version should instead carry the {{Wikimedia trademark}} and {{Cc-by-sa-3.0}} templates. The only logos that will not be licensed under CC BY-SA 3.0 are the MediaWiki and the Community logos, which were originally released under free licenses and do not need to be changed.

So, I wonder what's now the best course of action: Start a bot request simply replacing all {{Copyright by Wikimedia}} occurrences with {{Wikimedia trademark}} and {{Cc-by-sa-3.0}}? Or change {{Copyright by Wikimedia}} itself, i.e. changing it to a Wikimedia-specific cc-by-sa-3.0 + trademark template? Gestumblindi (talk) 20:17, 29 October 2014 (UTC)

I did change about half of {{Copyright by Wikimedia}} occurrences with {{Wikimedia trademark}} and {{Cc-by-sa-3.0}}, but got stuck with all the cases where {{Copyright by Wikimedia}} is mixed with several other license templates. For example {{Copyright by Wikimedia}}+{{Cc-by-sa-3.0}} should become "{{Wikimedia trademark}}+{{Cc-by-sa-3.0}}" not "{{Wikimedia trademark}} + {{Cc-by-sa-3.0}} + {{Cc-by-sa-3.0}}". But other combinations are less clear.--Jarekt (talk) 16:12, 30 October 2014 (UTC)

I think we should just change {{Copyright by Wikimedia}} template. --Jarekt (talk) 16:39, 30 October 2014 (UTC)

It's not that simple. In many cases the logo is included, or the work is a derived work. If the work is not CC-BY-SA 3.0, adding a CC-BY-SA-3.0 tag is wrong.

A good step forward, though, would be to fix the Wikipedia and Wikimedia screenshot templates.

Rich Farmbrough, 02:38 2 November 2014 (GMT).

Also is protected, and is a simple fix. Rich Farmbrough, 02:42 2 November 2014 (GMT).

October 30

Vindictive deletion requests

Is there any consistent Commons policy on how to deal with an editor who's launching a slew of deletions requests out of revenge because of a dispute about other things on English Wikipedia? --SergeWoodzing (talk) 11:33, 30 October 2014 (UTC)

• Consistent? Perhaps not. If the deletion requests are valid (e.g. the bulk of them are gathering consensus), the motive isn't that important, but if it's tit-for-tat raising of dubious deletions, that is usually considered unacceptable. - Jmabel ! talk 15:50, 30 October 2014 (UTC)
• Note: Duplicate discussionhere too. Jee 16:04, 30 October 2014 (UTC)

Thank you both! --SergeWoodzing (talk) 07:04, 31 October 2014 (UTC)

SVG Image Problems

I uploaded two files, 136th Signal Battalion Coat of Arms (Obsolete Insignia) and 449th Support Battalion Coat of Arms which both have something in the background at the top causing black bars to appear. What is causing this, and is it something y'all can fix for me?

Thanks, --Glasshouse (talk) 02:56, 31 October 2014 (UTC)

It is unsupported flowed text, go here: Help:SVG #Black rectangle (Flowed Text bug). Next time you can better ask in the COM:Graphics village pump. ↔ User: Perhelion (Commons: = crap?) 06:27, 31 October 2014 (UTC)

Media Viewer Update: New Improvements

Media Viewer's new user interface, with 'More details' button.

Prominent Disable/Enable tools make it easy to turn Media Viewer on and off

Hi folks: we're happy to let you know that our multimedia team has released many new improvements to Media Viewer in recent weeks, based on community feedback.

Here are some of the new features that are now live on Wikimedia Commons:

• An easier way to enlarge images by clicking on them
• "More Details" button: a more prominent link to the File: page
• Separate buttons for "Download" and "Share or Embed"
• An easier way to disable Media Viewer for personal use
• Re-enable Media Viewer from a file page
• Rename File page button: "Open in Media Viewer"
• Make MediaViewer text larger in Monobook
• A simpler metadata panel with fewer items
• Faster image load with thumbnail pre-rendering

You can try out these features on this 'Featured pictures' page.

Next, we are working on these last 'must-have' improvements for this release:

• A caption or description right below the image
• Move license label after source and adjust layout

(Note that the layout change above has just been released for testing on MediaWiki.org.)

These features are based on the most frequent requests from our recent community consultation and ongoing user research. For more information, visit the Media Viewer Improvements page -- or the Help FAQ page.

Many thanks to all the community members who suggested these improvements. Our research so far confirms that they provide a better experience for readers and casual editors, the primary target users for Media Viewer.

Please let us know what you think on this Media Viewer discussion page. We will post one more update in mid-November, once all improvements have been released and tested. Best regards. Fabrice Florin (WMF) (talk) 23:03, 30 October 2014 (UTC)

Is there a CSS/JS hack I can use to remove the "Open in Media Viewer" link on file description pages? I don't use it and don't intend to, so it's just extra junk cluttering up the page.   An optimist on the run! 23:25, 30 October 2014 (UTC)

Try

.mw-mmv-filepage-buttons { display: none }

In Special:Mypage/common.css (Or even meta:Special:Mypage/global.css) Bawolff (talk) 18:58, 31 October 2014 (UTC)

Thank you for the update, personally I think the Media Viewer is on the right track now. I'm looking forward to the last two outstanding changes. --Sebari (talk) 21:54, 31 October 2014 (UTC)

October 31

Search is currently too busy. Please try again later.

I have been getting this message for all Commons searches this morning in the past half hour. It's tripping up one of my projects quite badly. Is there a know bug? --Fæ (talk) 11:20, 31 October 2014 (UTC)

This is a know thing. See #search down?. Josve05a (talk) 12:15, 31 October 2014 (UTC)

Since when the searchfunction is ignoring "-" etc. , and why i get zero results somethings? :/ --Steinsplitter (talk) 12:18, 31 October 2014 (UTC)

Per wikitech:Server_Admin_Log, between 11:24 today 13:25 today, search was temporarily switched to the "old" search system due to the new (Cirrus) system breaking. There's more information about the cause at wikitech:Incident_documentation/20141027-CirrusSearch (tl;dr: The insource: operator had a bug where it used too much memory, causing the server to freeze. They have been temporarily disabled until the code can be fixed [13]). Bawolff (talk) 19:03, 31 October 2014 (UTC)

Chinese mainpage

• File:Chinese Wikipedia's Main Page screenshot zh.png
• File:Chinese Wikipedia's Main Page screenshot zh-hans.png
• File:Chinese Wikipedia's Main Page screenshot zh-hant.png
• File:Chinese Wikipedia's Main Page screenshot zh-cn.png
• File:Chinese Wikipedia's Main Page screenshot zh-sg.png
• File:Chinese Wikipedia's Main Page screenshot zh-hk.png
• File:Chinese Wikipedia's Main Page screenshot zh-tw.png

These pages have been diligently licensed with sub-licences of the included works. But then newer versions of the page have been uploaded. (And one of the works deleted, albeit for a valid reason - which means that the historical versions of the Chinese main pages won't work.)

Any solutions? Rich Farmbrough, 16:17, 29 October 2014 (UTC)