Commons:Village pump

↓ Skip to table of contents ↓       ↓ Skip to discussions ↓       ↓ Skip to the last discussion ↓

This project page in other languages: বাংলা | Alemannisch | العربية | asturianu | авар | Boarisch | bosanski | български | català | čeština | dansk | Deutsch | Ελληνικά | English | Esperanto | español | فارسی | français | galego | עברית | hrvatski | magyar | íslenska | italiano | 日本語 | kа | 한국어 | Lëtzebuergesch | македонски | मराठी | Nederlands | norsk bokmål | occitan | polski | português | русский | slovenčina | slovenščina | српски / srpski | suomi | svenska | ไทย | Türkçe | 中文（简体）‎ | 中文（繁體）‎ | Zazaki | українська | +/− Shortcut COM:VP Commons discussion pages (index) Commons Help desk Community-wide general discussion Copyright Proposals Graphics and photography discussion Image improvement Photography critiques Categories for discussion Deletion requests OTRS noticeboard Translators' noticeboard Work requests for bots Contact administrators Vandalism User problems Blocks and protections Bureaucrats' noticeboard CheckUser requests Dispute resolution #wikimedia-commons webchat Commons mailing list archive Bugzilla: Commons (last 7 days) Welcome to the Village pump This Wikimedia Commons page is used for discussions of the operations, technical issues, and policies of Wikimedia Commons. For old discussions, see the Archive. Recent sections with no replies for 3 days may be archived. Please note If you want to ask why unfree/non-commercial material is not allowed at Wikimedia Commons or if you want to suggest that allowing it would be a good thing please do not comment here. It is a waste of your time. One of Wikimedia Commons' basic principles is: "Only free content is allowed." This is just a basic rule of the place, as inherent as the NPOV requirement on all Wikipedias. Have you read the FAQ? For changing the name of a file see Commons:File renaming. Any answers you receive here are not legal advice and the responder cannot be held liable for them. If you have legal questions, we can try to help but our answers cannot replace those of a qualified professional (i.e. a lawyer). Your question will be answered here; please check back regularly. Please do not leave your email address or other contact information, as this page is widely visible across the internet and you are liable to receive spam. Purposes which do not meet the scope of this page Please do not make deletion requests here: use the relevant process for it instead. For technical support and graphics talks (PNG, SVG, GIF, etc.), please post on the Graphics village pump. To ask for image improvement, see: Graphic Lab/Photography workshop for photographs. Graphic Lab/Map workshop for maps. Graphic Lab/Illustration workshop for other illustrations. For translation requests, please post at Commons:Requests for translation. For photograph requests, please post at Commons:Picture requests. Search archives    Start a new discussion

Centralized discussion See also: Village pump/Proposals • Archive
Request for comment on standards for links to Wikidata and structured data. 19 August 2014 Request for comment on community consensus required for user rights changes. 28 July 2014 Request for comment on whether or not football kit images should contain logos. (11 July 2014) Propose to update CC license tags. (8 June 2014)
Template: View • Discuss • Edit • Watch

Village pump in India. [add]

Oldies

W.W.11

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

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

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 02

Re-sysopping of JurgenNL (talk · contribs)

October 03

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

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: OTRS ticket 2014100210006534--Sphilbrick (talk) 16:25, 4 October 2014 (UTC)

If by "can", you mean that Commons policy permits it, then I believe the answer is yes. (Parts of the Commons community unfortunately decided that it would be a good idea to push through a policy stating that Commons should ignore actual laws using a vote – which of course isn't how policy is made around here, but it's how this one was made.) If you mean that they can legally do it considering that this is a photographic reproduction created in Norway, then I would say no. Given that the uploader of the cropped version appears to be Norwegian, I think it's up to her to decide what level of risk she is willing to accept before the complaint is addressed. —LX (talk, contribs) 17:19, 4 October 2014 (UTC)

Just wanted to add that "File:Birkebeinerne på Ski over Fjeldet med Kongsbarnet.jpg", which is the original photograph showing the painting in its three-dimensional frame, is definitely not permitted on the Commons if the copyright holder did not consent because {{PD-Art}} does not apply to three-dimensional objects. I've tagged it with {{Non-free frame}}. Similarly, if the photograph had shown the painting at an angle hanging on a wall, that would also not be covered by PD-Art. — SMUconlaw (talk) 18:48, 4 October 2014 (UTC)

"When to use the PD-Art tag" got overwhelming support in that poll, and I'm confident we'd get the same overwhelming support today. Why should we have a policy unsupported by the WMF or a supermajority of Commons editors?--Prosfilaes (talk) 21:43, 4 October 2014 (UTC)

Which makes it a prime example of why policies shouldn't be decided through voting. —LX (talk, contribs) 09:28, 5 October 2014 (UTC)

Not unless someone gives some evidence that this policy shouldn't exist.--Prosfilaes (talk) 23:24, 5 October 2014 (UTC)

In this case, there were significant objections preventing the policy from being passed based on a true consensus, so instead the discussion was cut short in favor of a simple headcount. Voting only takes into account what people want (usually: as many illustrations as possible), not whether what they want is legal or based on sound arguments. —LX (talk, contribs) 13:15, 6 October 2014 (UTC)

No, it would not be appropriate to reduce the resolution. If the uploader is concerned, then we should act on that, but that we can use copies of 2D public domain art is strong, highly agreed-upon, policy.--Prosfilaes (talk) 21:43, 4 October 2014 (UTC)

Another version exists and was replaced in this article by the original uploader. The original uploader is User:Electristan and is not an eager contributor (and has not contributed to norwegian Wikipedia i.e. probably not Norwegian). The upload does not say who the photographer were. Does Sphilbrick have any information about why the complainant assumes the photograph is taken by him/her? The painting is available to the public in a public place. -- ツ^ツ Dyveldi  ☯  10:55, 5 October 2014 (UTC)

As noted on File:Birkebeinerne på Ski over Fjeldet med Kongsbarnet.jpg, it is claimed to be ©: O. Væring. The person writing in is a representative of O.Væring.--Sphilbrick (talk) 16:01, 5 October 2014 (UTC)

Thanks Sphilbrick. The photographer O. Væring died in 1906 and left a firm behind. The Norwegian National Library has quite a few photograpies freely avaliable to the public by O. Wæring. Judging the ages of this photography can't be done by the age of the photographer O. Væring or the age of the firm (they also had a lot of photographers working for them). The original picture is depicted here and has a quite different frame. At Norwegian Wikipedia we now wonder if this photograpy is a photography of a reproduction. If the company O. Væring has taken the photography they should be able to provide an accurate date/year and where the photograpy was taken and if this is i photography of a reproduction or not. They should also be able to identify why this photography belongs to them (is downloaded from their nedsite etc?). If this is a photography of a privately owned reproduction taken by a private person I most certainly do not know the copyright status. -- ツ^ツ Dyveldi  ☯  17:50, 5 October 2014 (UTC)

Without knowing the history of the piece at Holmenkollen Skimuseum and what claim there is in the OTRS Ticket, it is a bit difficult to say if it is legal or not to publish it here. The original painting is old and "falt i det fri" (protected for 70 years after the creator died) in Norway, that is approx public domain or perhaps more like a CC-by-sa with some limits on how you can use it, like a kind of very limited nd-ish or what you would call ideal rights. You can resample, but not if that degrade the original painting or the creator. It is also an open discussion if resampling is legal if it does not add any artistic value, but lets not go down there. If you take a photograph of the original without adding any artistic value the photo is what we call "fotografi" or "photography" and not a "fotografisk verk" or "photographic artwork". Such a photography has protection, but it is somewhat limited compared to the original creator. It can not limit or change the rights of the original creator or his artwork. When a photo is old (50 years from the creation or 15 years after the creator died) it will be public domain, and not have any further protection. If that copy is not made as a photo/-graph it would not have any protection at all. A scan of a photograh would neither have any additional protection. If the photo is made as part of the photographers job at a firm the firm acquires the rights, but then the protection only runs for a very limited timespan 50years from the first publication creation of the photo. If you acquire a legal copy of a photo that has "falt i det fri" you are free to use it any way you please, as long as the original photo is "falt i det fri". So the question is; is this photo of a reproduction, is the reproduction of an original, and when did that happen.

The company O. Væring is known to do scan of old books and republishing those scans. If that has happen here I do not know, but the company should produce some hard facts about who made the photography and when. In short O. Væring must substantiate their rightful claim, otherwise it is likely that what they have is just a claim on a photo made to create a reproduction that has "falt i det fri".

I would say go with the official position taken by the Wikimedia Foundation and let O. Væring send a take down notice, then they must substantiate their claim. In the mean time somebody should check the painting/reproduction at the Holmenkollen Skimuseum. Perhaps check some other sources too. Jeblad (talk) 13:16, 5 October 2014 (UTC)

you might want to review Commons:The_Commons_Log/2009#National_Portrait_Gallery_copyright_dispute; w:National Portrait Gallery and Wikimedia Foundation copyright dispute. NPG and others have a view, and WMF has another. i would also change the license to PD-art/PD-100 Slowking4 ♡ Farmbrough's revenge 12:13, 7 October 2014 (UTC)

October 05

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

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)

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

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

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

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

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

October 08

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 (119,311 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)

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

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

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)

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)