Last modified on 17 September 2014, at 19:52

Commons:Village pump


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

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

Welcome to the Village pump

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

Please note


  1. If you want to ask why unfree/non-commercial material is not allowed at Wikimedia Commons or if you want to suggest that allowing it would be a good thing please do not comment here. It is a waste of your time. One of Wikimedia Commons' basic principles is: "Only free content is allowed." This is just a basic rule of the place, as inherent as the NPOV requirement on all Wikipedias.
  2. Have you read the FAQ?
  3. For changing the name of a file see Commons:File renaming.
  4. Any answers you receive here are not legal advice and the responder cannot be held liable for them. If you have legal questions, we can try to help but our answers cannot replace those of a qualified professional (i.e. a lawyer).
  5. Your question will be answered here; please check back regularly. Please do not leave your email address or other contact information, as this page is widely visible across the internet and you are liable to receive spam.

Purposes which do not meet the scope of this page


Search archives


 


Centralized discussion

See also Commons:Village pump/Proposals

Please help by translating these messages into other languages.

Note: inactive discussions, closed or not, should be archived.

Archive  • Discussion • Edit • Page history • Watch
Thatched water pump at Aylsham, Norfolk [add]





OldiesEdit

Librarian congress imagesEdit

Hello, there's a lot of CC-By-SA images of the World Libraries Congress (Lyon, France) on FlickR: could anyone download them on Commons? Best

Backup KML filesEdit

I put the question on OCTRS but got no response, as this is not directly a lcence or permission issue. I tested and .kml files are stil not accepted.

I researched a lot vicinal Belgian railway lines, drew the lines in My maps on Google maps and linked them via Google Maps in articles. examples in:

nl:Buurtspoorwegen van de provincie Brabant#Geëlektrificeerde lijnen rond Brussel.

The underlying format KML files in My Maps are my ownership. (Google does not allow to make them community property) They can be used on any underlying maps, for example Openstreetmap. Unfortunately this format cannot be imported in the Commons. The danger is if I die, My Maps in Google Maps wil be lost for the wikimedia community. I have zipped all the kml files. Can I send this file to OTRS as backup? Of course I give my permission to use these files under a opensource licence.Smiley.toerist (Overleg) 22:29, 26 August 2014 (UTC)

Wich email adres can I use? (permissions-commons-at-wikimedia.org is probably not a good adres)Smiley.toerist (talk) 11:27, 5 September 2014 (UTC)

OTRS is definitely not the right place to store (non-confidential) files just for the sake of storing them. Maybe ask Openstreetmap. Or upload your files to OneDrive and share them from there.    FDMS  4    17:44, 5 September 2014 (UTC)
Since kml is just an xml text file you could simply copy the kml contents into a user subpage. MKFI (talk) 07:23, 6 September 2014 (UTC)
For the purpose of experimentation I have done this at:

User talk:Smiley.toerist/test area kml files

Is this usable and can this be update with a tool in the Commons? Smiley.toerist (talk) 07:27, 12 September 2014 (UTC)

Chinese?Edit

I am trying to add translations to File:Decoder Example.svg, and I copied the two flavors of Chinese, from File:1 bit Decoder 2-to-4 line.svg and File:1 bit Decoder 2-to-4 line zh hant.svg, but can not get zh-Hans to work. When I choose it I only get the default, but simplified Chinese shows up in the drop down box. I started by using zh-CN and zh-TW, but that not work, for either of them. zh works. I have been using zh on other diagrams, but is that supposed to be Simplified Chinese or Traditional Chinese? I have been using Traditional. Delphi234 (talk) 20:14, 5 September 2014 (UTC)

Due to librsvg not following the SVG specification, things don't really work right when you have multiple language codes that are both subtags of the same base language in the same switch (e.g. having zh-Hant and zh-Hans together). Which is really unfortunate. See also [1]. Bawolff (talk) 02:23, 9 September 2014 (UTC)
Thanks. So for now the answer is that only one zh flavor can be included using <switch> and the others need to be placed into a separate file. The drop-down box is picking up the additional languages, but rendering does not. Delphi234 (talk) 21:45, 11 September 2014 (UTC)

September 06Edit

plant galleries - overview or strictly botanicEdit

Hello,

I am one of those people who still think that galleries are a good idea on commons - ideally well-linked galleries providing an overview of a topic - that in case of a plant should be acceptable and comprehensible to both botanists and non-botanists.

I now had an experience that was quite frustrating to me, as the overview gallery "Rosa" - one of the galleries I had put a lot of effort into - was moved to the lemma Roses in cultivation (a lemma not really fitting the overview idea of the gallery) and Rosa was changed into a species gallery (moved from the lemma "Rosa species"). When I asked MPF for his reasons for the move, he stated that he wanted "to bring it line with other taxon classifications galleries with a taxobox", that the overview gallery is not "a scientific taxon gallery with listing of the species, so does not have a taxobox, nor belong at the scientific genus name, but have (per Commons language policy) a vernacular language title (default language, English)."

He further told me that "Computer robots are far less versatile, and this is where the problem lies: organisations like the Encyclopedia of Life (EoL) harvest many of their photos robotically from Commons, and they do so by detecting the Taxonavigation and using that to direct the images to the correct EoL taxon page. But they only want natural biological taxa, and don't want to be cluttered up with thousands of pics of plant cultivars (or domesticated animals) as these are not biological taxa. On Commons, having multiple galleries to cover different aspects of a topic is no problem at all, so separate galleries for the biological taxa under the scientific name (and with taxonavigation), and for cultivars and other wider aspects (without taxonavigation), is very sensible."

I now wanted to ask what the general opinion is, as apparently my idea of overview galleries (which beside the species would also includes pictures and links of the plant in art, in cultivation, in floristry, as ingredient or whatever other aspects are available on commons) doesn't fit with this bot(any)-centric view. At the moment I'm unsure if and how I should continue with the maintenance of plant galleries, as the galleries I'm creating are made for humans and not for bots. I can understand that galleries with a picture of each species in a genus are important for bots - but is it necessary to tailor the main gallery of a plant (and Rosa is viewed about 80 times a day) for them? For Rosa, that means that the main gallery only covers one aspect of a vast topic, suppressing all other facets - and there are other agricultural and gardening plants that would have the same problem.

If I understand MPF's explanation correctly, the taxonavigation is apparently linked to the bots and therefore can't be used as navigation tool in "non-scientific galleries" (or "non-bot-compatible galleries"). Do we have to create a second taxo-navigation-template that can be used for readers?

Perhaps I'm misunderstanding the issue - or it is a problem that was already discussed and decided - in either case, I'd really like some advice/opinions...

Best wishes, --Anna reg (talk) 23:19, 6 September 2014 (UTC)

IMO, “galeries” (that is, “article” pages, as opposed to ranks and files of media thumbnails from category pages) have no place whatsoever in Commons. If you want to create (and mantain) an image gallery about a given subject, botanical or not, do it in Wikipedia (in the language or languages of your choice). I suppose this is not the answer you needed, but it is one of the three only things I have to say about mainspace pages in Commons. -- Tuválkin 01:25, 7 September 2014 (UTC)
I can't speak for other languages but galleries tend to have only a limited role on English Wikipedia articles. Instead it is suggested that generally galleries are more appropriate on Commons. Green Giant (talk) 02:13, 7 September 2014 (UTC)
As someone who has moved galleries from en and other language wikipedias to here, I disagree with User:Tuvalkin, I treat galleries as thematic photo articles.--KTo288 (talk) 09:00, 8 September 2014 (UTC)
  • The main problem with galleries is that they are often not maintained. So thanks for your work maintaining galleries! But the taxo tree only makes sense if all the nodes in the tree are unique and are about a taxonomic identity. To me it certainly makes sense to have a species page and a separate page dealing with other aspects not related to that taxonomic entity. To start with the scientific separation of different plants and animals into separate species often does not correspond to general historic and current divisions used by people. Eg there are lots of different animals that are known as rats which don't fall within the genus rattus. So (without knowing the specifics about roses), I would expect an overview of all things relating to "rose" would not be part of the taxonomic tree. I would expect there to be {{See also|...}} links between the taxo tree rose page and the rose overview page though. So strictly botanic galleries in the taxo tree, other galleries "see-also" linked, but not in the tree. --Tony Wills (talk) 10:02, 7 September 2014 (UTC)
Your rattus comparison is not true for the plant cultivars I'm talking about - the cultivars do belong into the Rosa genus as they are hybrids of Rosa species (even though in some cases the border between species and cultivar is a bit bleary). The same is true for Tulipa and all its cultivars or Narcissus, Dahlia, Hosta, Iris, Lilium, Paeonia, Camellia, Clematis, Malus, and many more... (those galleries handle the cultivar/species problem differently - in some cases not mentioning them at all, some providing the see also-link, in some cases with a few selected cultivar pictures and a link to the main cultivar gallery the method I prefer, as it shows you what to expect - and images are more important on commons than text).
I think my main problem is that I can't understand how other aspects of a plant - that naturally have to be categorised in that plant category - should not be related to the biology of the plant. I am no botanist, but if I look up a spice, fruit or cultivar, I'm interested in it's biology. The content of the gallery now called Roses in cultivation is not so different than the article Rose on the English wikipedia (where the wild species were also delegated to a subpage, as there are simply to many to list them all in an overview).
Best wishes, --Anna reg (talk) 23:37, 7 September 2014 (UTC)
If the overview just included species, varieties and cultivars then, to me, it would be appropriate as part of the taxo tree as all the specimens are genetically part of that species. But other sections don't really fit, eg rose gardens, compass roses. But I am wondering where we place genetic engineered plants/animals with cross species genes, sort of gets the taxo trees into a knot (even 'simple' cross breeding of camels with lamas puts a kink in things). --Tony Wills (talk) 03:06, 8 September 2014 (UTC)
There's no reason why a gallery can only have one unique category if it rightly belongs to more than one branch of the tree. Its used rather more with regards categorisation of categories themselves rather than galleries, but for many plants and animals we categorise one based on taxa their biological aspect, and second based on their use, as food, how they are used, and on the basis of what products we derive from them e.g. fibers. I think of categorisation as not simply a tree, but as more like a vine with multiple stems, and some categories as being where nodes from one or more stems intersect. So for your roses example, for me I'd keep the bot readable categories for bots, and add human categories for humans, so e.g. link it back into category gardens by way of category:ornamental plants.--KTo288 (talk) 09:00, 8 September 2014 (UTC)
I thought we were talking about the Taxonavigation tree which uses templates, rather than categories. --Tony Wills (talk) 22:30, 8 September 2014 (UTC)

I could imagine changing the overview style to the sections species, cultivars, possibly plant parts, and see also (plant in cultivation, plant in art, plant as aliment, etc. with only one picture and a link for those topics) - that would still mean that there are other pictures than the species pictures in the taxo-gallery, which MPF's opinion is a problem for bots. As I said, I'd really like to find a solution I can work with in the future, as I'd really prefer if the genus and cultivar pages are better connected in future - and not worse. The other option I see (if it really is necessary to have all species in the main taxo-gallery instead of subpages called 'xxx species'), would be to create overview galleries under the vernacular names, but that sounds like a really bad idea to me, as it would be quite confusing. --Anna reg (talk) 11:23, 8 September 2014 (UTC)

Sorry, I've been rather busy the last few days so only had minimal time for Commons editing. I guess the most important point to make is that there is no limit to the number of galleries; it is not an "either/or" of overview or strictly botanic, it can very easily be both. For naming galleries, the strictly botanic should take the botanical name, while the overview is probably usually best at the English name, as that's the general Commons naming proceedure standard, and is what most Commons users expect. Although the overview gallery that I renamed from Rosa I called "Roses in cultivation", I'd have no objection to its being moved to just "Roses". Of some of the other cited examples, the Malus gallery contains several sections which cover just the cultivated forms of one species alone; in line with their head category Category:Apples, these would be better split out to a new gallery titled Apples; that is after all, where the vast majority of people are likely to look for it (I'll work on this over the next day or two). I agree that related overview and botanical galleries should certainly be cross-linked, best with the {{Main|Xxxxx}} or {{See also|Xxxxx}} linking format depending on context.
To @Tony Wills:, yes I agree that things like genetic engineered organisms and animal hybrids don't fall into taxonomic categories and galleries. Taxon categories with taxonavigation should only contain taxa as defined by the ICBN and ICZN; non-taxa like cultivars (which come under the purview of the ICNCP), engineered organisms, animal hybrids, etc., are best given separate galleries, without taxonavigation. An odd cultivar appearing here and there on a taxon gallery does not matter, but swamping a taxon gallery with mostly cultivar pics should be avoided.
Hope this helps! - MPF (talk) 13:22, 11 September 2014 (UTC)

September 07Edit

Proposal to disable StockPhoto gadgetEdit

I propose to disable the by default enabled StockPhoto gadget, which relies on the same information as MMV for it's licensing. This gadget has been enabled for years, but even initially there were questions about the legal situation. It has not been worked on significantly for the years since Magnus, Krinkle and Diebuche stopped improving it. Since there are still over 690000 files without any Commons:Machine-readable data, i propose we clean that up, before we try to encourage people to use material from our website. —TheDJ (talkcontribs) 08:07, 7 September 2014 (UTC)

690000 out of 22698513 is 3% or one in 33 files have this problem. This should of course be improved, but disabling the gadget is too much.
I've learned several people how to use this to properly reuse files. They would be lost without it (no, they don't login). What I am interested in is usage statistics. How many people are actually using it? How many different images? How many images without proper metadata are actually opened in the gadget?
My assumption is that the quality of these 690000 files is well below our average quality. You see the same with our uncategorized files. Good quality images and good quality metadata seem to go hand in hand. Multichill (talk) 09:43, 7 September 2014 (UTC)
Ah, I have always wondered where these icons come from. I think TheDJ raises a good point, and this should be improved or disabled. I'd like to add a few things to the "improve" list -- but now that I know where to go, I'll make those points at Help talk:Gadget-Stockphoto. -Pete F (talk) 19:18, 12 September 2014 (UTC)

Encouraging pro photographers to contributeEdit

I've just been reading our well-written obituary to Jorge Royan, a pro photographer and commons contributor, who "donated hundreds of beautiful photos to Wikimedia Commons so that, in his own words, they won’t stay lost in his computer when he’s no longer around and serve a greater purpose other than just as a curiosity to his grandchildren".

It had me wondering if we have a page or project dedicated to encouraging individual professional photographers to contribute. I often speak to such people, and they usually express concerns about losing money, or people mistakenly thinking that all of their pictures are freely reusable. It would be good to have a FAQ or other document which specifically addresses their concerns, and perhaps has some examples of good contributions from pros. I'd be willing to help put a page together. Andy Mabbett (talk) 11:53, 7 September 2014 (UTC)

As an amateur sport photographer, I met a lot of sport photographers. During the 2014 Rugby World Cup, I've talk with a sport (pro) photographer. She tried to upload a photo on Wikipedia. But each time, her photo was deleted. So, we probably need to improve our documentation ;) Pyb (talk) 14:05, 7 September 2014 (UTC)

CC 4.0 side issueEdit

We put barriers in the way of pro photogs that causes images to be deleted if they don't provide OTRS confirmation they have the copyright to the image being offered. Regardless, CC 4.0 probably killed any chance we had of convincing pro photogs of the validity of creative commons licensing. Saffron Blaze (talk) 22:39, 10 September 2014 (UTC)

Can you elaborate on the 4.0 issue, or point to somewhere that does? The Wikipedia article makes it sound like 4.0 just tightened up the legalese for international jurisdictions, without changing the intent. --Ppelleti (talk) 04:23, 11 September 2014 (UTC)
Ppelleti, I don't remember where the discussion took place, but as I recall (and someone correct me if I'm mistaken) the interpretation of the wording of 4.0 meant that professionals could not contribute lower resolution images freely and retain non-free copyright on higher resolution versions...that releasing one resolution under Creative Commons meant that all resolutions would fall under the same license. This raised a lot of concerns amongst those who contributed like this, and rightfully so. I think it was a huge mistake on the part of the CC team, insofar as it relates to our mission on Commmons. Huntster (t @ c) 05:05, 12 September 2014 (UTC)
There's https://wiki.creativecommons.org/Frequently_Asked_Questions#Can_I_apply_a_CC_license_to_low-resolution_copies_of_a_licensed_work_and_reserve_more_rights_in_high-resolution_copies.3F and also some discussion at Commons:Village_pump/Copyright/Archive/2014/06#Could_someone_please_post_a_summary_of_this.3F - I was under the impression [IANAL] that it wasn't so much a cc 4.0 issue as much as the issue just generally being ambiguous. Bawolff (talk) 01:01, 16 September 2014 (UTC)

Photos and video from unmanned aerial vehiclesEdit

I find it unlikely that we only have five files in Category:Photos and video from unmanned aerial vehicles. Do we have others, miscategorised or uncatgeorised? Andy Mabbett (talk) 11:59, 7 September 2014 (UTC)

I've found some more with a search not in category, but there appear to be quite a few more in Category:Aerial views of the domain of Versailles which I've added as a subcat. There probably are a lot more somewhere out there. Green Giant (talk) 12:42, 7 September 2014 (UTC)
Surely Category:Satellite pictures should be included as a sub cat? -- Tuválkin 13:30, 7 September 2014 (UTC)
Please don't, satellites are spacecraft not aerial vehicles (aircraft). --El Grafo (talk) 22:22, 7 September 2014 (UTC)
Good point. -- Tuválkin 13:25, 11 September 2014 (UTC)

Toollabs facilitating MP4Edit

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

September 08Edit

Censorship facilitation - Hard to find a complete list of a user's uploadsEdit

It used to be easy to find a list of a user's uploads. I'm trying to figure out why there are only 47 files in https://commons.wikimedia.org/wiki/Category:NSA_ANT - what has been deleted and if any of it censored.

Special:ListFiles doesn't Special:Contributions doesn't.

Some files that I uploaded don't appear on my watchlist; it seems they've been deleted from commons and deleted from my watchlist. Some don't appear on my watchlist, but are still up, like File:Nsa-ant-waterwitch.jpg --Elvey (talk) 21:00, 8 September 2014 (UTC)

Are you looking for the upload log? That shows deleted files as well, while Special:ListFiles and Special:Contributions don't. darkweasel94 21:09, 8 September 2014 (UTC)
Deletion does not change watch statuses, and you can watch any page whether existing or not. See the red links on Special:EditWatchlist.    FDMS  4    21:27, 8 September 2014 (UTC)
Note that normal edits are removed from Special:Contributions after being deleted, so uploads aren't unique in that regard. Bawolff (talk) 01:58, 9 September 2014 (UTC)
Since when, and more importantly, where's the community discussion supporting the change?--Elvey (talk) 07:03, 9 September 2014 (UTC)
Elvey Since at least 2003 possibly earlier (I'm not familiar with pre-phase 3 software, so I can't say what things looked like earlier). (proof + [2]). I'm not sure why you expect a discussion for something that has literally been that way since the beginning of time. Bawolff (talk) 00:23, 11 September 2014 (UTC)
Elvey, I assume you were talking about the files you uploaded with the names "File:Nsa-ant-<code name>.jpg"? As far as I can determine, while some of these were not deleted, the ones that were deleted were deleted with the rationale "Exact or scaled-down duplicate". Given that these files were in Category:NSA_ANT and we know the ANT catalog has 48 pages (one more than the currently 47 files in the category), I think the files you uploaded were correctly deleted as duplicates, except for File:Nsa-ant-typhon-hx.jpg. I'm not an admin, so I can't see the file, but going by the name that was presumably page 42 "TYPHON HX" from the ANT catalog. That page currently does not appear in Category:NSA_ANT, so I think you can legitimately ask that File:Nsa-ant-typhon-hx.jpg be undeleted over at Commons:Undeletion requests. —RP88 (talk) 02:40, 9 September 2014 (UTC)
Getting slightly off the original topic, it seems like it would be nice if the "Exact or scaled-down duplicate" message would include the name of the existing file which it was believed to be an exact or scaled-down duplicate of. Or maybe even replace the duplicate file with a redirect to the original file, rather than completely deleting it? --Ppelleti (talk) 05:49, 9 September 2014 (UTC)
Responding to my own comment, sometimes the "Exact or scaled-down duplicate" message does include the name of the other file; I wonder why it didn't in the case of Elvey's files? --Ppelleti (talk) 05:57, 9 September 2014 (UTC)
Yes, good catch. Odd. But Denniss does a rogue stuff.--Elvey (talk) 08:11, 9 September 2014 (UTC)
Thanks, RP88! Yes and no. I knew why the bulk of them were deleted, but was concerned that the deletion was overzealous, and you've confirmed I was right. If a passing admin could please undelete File:Nsa-ant-typhon-hx.jpg, I'd appreciate it. Otherwise, I'll head to Commons:Undeletion requests.--Elvey
File:Nsa-ant-typhon-hx.jpg undeleted. Yann (talk) 08:08, 9 September 2014 (UTC)
Thanks!--Elvey (talk) 08:11, 9 September 2014 (UTC)
Thanks again! I appreciate the help. I think one of the missing pages is on FOXACID; I don't have the ANT catalog page, but I did just upload File:NSA_ANT_FOXACID.jpg.
However, my concern - It used to be easy to find a list of a user's uploads, and it's been getting harder and harder - still needs to be addressed. Again:
At the very top right of any page is "Uploads", and near the top of the page that clicking "Uploads" brings up, it says, "This special page shows all uploaded files that have not been deleted; for those see Special:Log." But that's false. It was true; I had that link added myself, because it used to be easy to find a list of a user's uploads, and it had been getting harder. To no avail. Why is Special:Log broken? How is a user supposed to figure out that Special:Log/upload/Elvey is the place to go? MediaWiki_talk:Listfiles-summary#Deleted_Uploads - I posted here asking for a fix to the latest breakage. --Elvey (talk) 07:03, 9 September 2014 (UTC) (updated)
How do you feel Special:Log is broken? Special:Log has a number of types of log entries including uploads. But if you only want a specific person's log, than you have to fill out the text box at the top. Its always been this way. Bawolff (talk) 00:27, 11 September 2014 (UTC)

September 09Edit

Echo and watchlistEdit

Special:Notifications & Special:Watchlist substantially overlap in functionality, except the former also contains extra (some non-public) events and doesn't provide with passive usage options (means to turn off web-nagging or email-nagging and to just keep visiting the page whenever I'm free), while the latter doesn't provide with options of active web-nagging notifications (but already provides email interface). Partly, in my personal view, the Echo/Notifications project was driven by low usability of watchlist; [3] comes to mind. It's also perhaps worth noting that Echo users aren't exposed to Special:Notifications unless thy have JavaScript disabled — in which case it's their only means of reading the notifications.

I'd like to get this done:

  1. Merge these two pages into one.
  2. To remedy large inflow of information, introduce multiple levels of importance of the web-nagging notifications (red for mentions, orange for thanks, blue for new watchlist items, etc and configurable in your settings).

Thoughts on both, please? --Gryllida 02:21, 9 September 2014 (UTC)

I think the idea was that Echo was supposed to be to notify you of things directed specifically at you (Thanks, edits to your talk, pings, etc) where watchlist is more about things you're interested in, but aren't directed squarely at you (ie Page edits to pages on your watchlist). Having such information distinct does kind of make sense - echo in theory should be a low traffic place [whether that's true in practise is debatable] where things needing more immediate attention are found (Since they are directed to you personally), compared to a watchlist which is more a RecentChanges for things you care about. Watchlist might have thousands of pages on it, and if there are more recent edits then you care to keep up with on your watchlist, that's ok or even expected, but if you can't keep up with your notifications, that is perhaps more of a bad thing. This distinction seems to totally get muddled with flow however... Bawolff (talk) 02:35, 9 September 2014 (UTC)
You're right, it's probably just a Flow problem. It is the thing that appears in both watchlist and notifications in the first place. --Gryllida 22:31, 9 September 2014 (UTC)
I don't think that Notifications and Watchlist "substantially overlap in functionality". Notifications tells you when a link to your username was added to any page (not just a page on your watchlist). Edits to pages on your watchlist are not shown in your notifications unless there was a link to your username in the edit summary. In any case, any "merger" would probably have to be the result of developers working on Wikimedia software in general, not something that can be done on Commons only. AnonMoos (talk) 10:34, 9 September 2014 (UTC)
Special:Notifications is exposed to anyone who middle-clicks the notification icon at the top of the page, not only to people who have javascript switched off. I think that Special:Notifications is for pages which need urgent attention whereas Special:Watchlist is for pages which do not need as urgent attention. --Stefan4 (talk) 14:13, 9 September 2014 (UTC)
Thanks I didn't notice that. Gryllida 22:31, 9 September 2014 (UTC)
And via notification icon > All notification …    FDMS  4    14:38, 9 September 2014 (UTC)
They I think plan to remove it but I'm not sure (this discussion). --Gryllida 22:31, 9 September 2014 (UTC)
I define "overlap in functionality" as some items (replies in Flow, for instance) being capable of appearing on both watchlist and in echo notifications. This is confusing, which is a problem. It occurred to me, thanks to a message above, that it's probably a Flow problem. --Gryllida 22:31, 9 September 2014 (UTC)
I don't really think the Commons village pump is a good forum for this, as none of this is Commons-specific, but I do think there is a point here: currently, there is a separate preference for email notification upon a watchlist event. If the watchlist were integrated into the notification system, there could be an additional event "Notify me when a page on my watchlist is changed", and an additional notification type "show on watchlist". That way, users could do interesting things like showing pings only on their watchlist or getting a red notification button upon all watchlist events, and the preferences for when to get an email would all be in the "notifications" section of Special:Preferences. I'm just brainstorming here, I've no idea how feasible (or even desirable) that is, but if any developer reads this, perhaps they'll like this idea. I don't think Special:Watchlist and Special:Notifications should be merged, but they could be changed so that both can display events currently shown on only one of them and the user can choose what to display where. darkweasel94 15:13, 9 September 2014 (UTC)
Hook watchlist into Echo and be done here? Perhaps it's moderately good if we remove the means to email watchlist items from outside Notifications. Then we'd have to have 2 hooks: watchlist minor change and watchlist major change. Besides, the two pages (watchlist and notifications) would contain even more common content, and I'd realise that I'd've already read some of these things by the time I visit a second page of these two. --Gryllida 22:31, 9 September 2014 (UTC)
Frankly, Notifications has been the one among all officially sponsored “gadgets” that has been useful and non-disruptive for me. I’d love if it were left alone in terms of any big changes — «Merge these two pages into one» seems to be an especially bad idea. -- Tuválkin 13:21, 11 September 2014 (UTC)

New user limitationsEdit

I'm doing some training in a few days, and have been asked to cover more about Commons than I usually do for newbies (who I generally teach only to edit Wikipedia, in the first session). What limits are newly signed-up users likely to encounter? Can they upload and categorise images on day one? Is there a wait period for new accounts? (If this is documented somewhere, please feel free to point me at it). Andy Mabbett (talk) 23:43, 9 September 2014 (UTC)

In simple terms, actions that new users with a new account of less than four days can't perform are listed at Commons:Autoconfirmed users. More technically, it would be the difference between the rights of "users" and "autoconfirmed users" on Special:ListGroupRights. -- Asclepias (talk) 00:08, 10 September 2014 (UTC)
And not to forget Special:AbuseFilter/110, which I ridiculously cannot view it but I think new users cannot upload more than 8 images at one time. -- Rillke(q?) 21:29, 11 September 2014 (UTC)
Thanks, both. Andy Mabbett (talk) 12:39, 13 September 2014 (UTC)

September 10Edit

fault .gif thumbnailsEdit

Hi

I'm not sure where to ask this question, is there a way of fixing the thumbnails for these .gif files? Once you've clicked through to the main file it works fine but the thumbnails have not been generated.

Thanks --Mrjohncummings (talk) 04:22, 10 September 2014 (UTC)

There's a limit on the maximum pixel count that a lossless image can have and still have thumbnails be generated from it on Commons. The limit has been changed from time to time, but is usually around 25,000,000. File:Cigarette sales per Capita in the United States, 1970 - 2012.gif has 1,280 x 737 x 43 pixels, or 40,564,480... -- AnonMoos (talk) 14:30, 10 September 2014 (UTC)
I'm pretty sure this is bugzilla:47409 --AKlapper (WMF) (talk) 15:17, 10 September 2014 (UTC)
The thingy that makes smaller versions of images is limited to 400 MB of ram. In cases like these (error code 137 if you try and download the thumbnail), it went over the ram limit. (There is also a hard megapixel limit where it won't even try, currently set to way too high apparently). It can be worked around by uploading a smaller version of the image. Bawolff (talk) 00:38, 11 September 2014 (UTC)

Edit

Unless someone can prove an official change, we need to undo the change to the MediaWiki logo at File:MediaWiki-smaller-logo.png. • SbmeirowTalk • 19:07, 10 September 2014 (UTC)

✓ Done. --Túrelio (talk) 19:20, 10 September 2014 (UTC)

Wikilegal/Removal_of_watermarks_from_Commons_imagesEdit

In response to the WMF opinion provided in the title there is discussion ongoing about how we on Commons will address the legal risks of removing watermarks and/or copyright notices (aka CMI). Saffron Blaze (talk) 22:43, 10 September 2014 (UTC)

I would summarize the conclusion as nothing to see here—it is inconclusive as it states that the way we work at the moment is "most likely" fine and advises uploaders that they are better off "consulting their own attorney".
It would be refreshing if these series of essays from WMF legal interns actually broke new ice, and could be used in lobbying for change rather than hedging bets.
If the Wikimedia Commons community wants legal advice, then we would be much better off asking for a grant to pay a legal expert for a solid opinion, or to pursue a clarification from a trusted advisory organization. The Foundation does not exist to fill this need. -- (talk) 07:38, 11 September 2014 (UTC)
Of course they are indeed this vague partly on purpose, to protect the organization by keeping liability with the contributors, safe harbor, and also partly because that's just the actual situation. It's America, judges usually have an enormous amount of leeway with interpreting the law, and many of our problems are exactly in the area that interpretation by the judge would be required. I've had a few discussions with Legal team members during Wikimania, and it was quite enlightening I must say. —TheDJ (talkcontribs) 09:30, 11 September 2014 (UTC)
Actually there is something significant here. WMF legal are unable to recommend removing watermarks from CC images. Yet CC BY-SA is supposed to be designed to permit images to be free to reuse, modify, adapt, crop. So if the licence is unclear on our response to a practice that is widespread throughout the internet (watermarking) then it is not fit for purpose. WMF should spend its money working with CC to create a licence that has fewer of these legal uncertainties. We've seen this before with issues surrounding image resolution and doubts about what exactly is being licensed. Essentially, every time we ask WMF legal to clarify an issue surrounding CC licenses, and they respond with something vague, they should treat that as a bug report on the CC and consider how they can fix this for v5.0. -- Colin (talk) 13:03, 12 September 2014 (UTC)
Quite significant if you care about editors. WMF has said legal risk for removal of watermarks (CMI) appears to be increasing as case law has been moving in the direction of more liberal interpretations of what is CMI. Saffron Blaze (talk) 01:12, 13 September 2014 (UTC)
Fæ -- when Mike Godwin was the one delivering such advice, he almost always opted for the more lenient or permissive interpretation of copyright etc. law, to the degree that some on Commons lost respect for his advice. Not sure which situation you'd prefer... AnonMoos (talk) 20:40, 14 September 2014 (UTC)

September 11Edit

VisualEditor available on Internet Explorer 11Edit

VisualEditor-logo.svg

VisualEditor will become available to users of Microsoft Internet Explorer 11 during today's regular software update. Support for some earlier versions of Internet Explorer is being worked on. If you encounter problems with VisualEditor on Internet Explorer, please contact the Editing team by leaving a message at VisualEditor/Feedback on Mediawiki.org. Happy editing, Elitre (WMF) 07:29, 11 September 2014 (UTC).

PS. Please subscribe to the global monthly newsletter to receive further news about VisualEditor.

WMF’s VE and MSIE. Yep, those two has a lot in common, when you think about it… -- Tuválkin 13:13, 11 September 2014 (UTC)

Category:<artist>Edit

Hello, include images of artworks by artist A in the category artists A? Some sort as other sort so, what applies? Thank you. Regards --Jean11 (talk) 15:17, 11 September 2014 (UTC)

  • In general, work by a particular artist belongs either directly in the category for that artist or in a subcategory. Subcategories might be as broad as "Work by Artist A" and as narrow as a single work, or even occasionally more narrow (e.g. reproductions of a particular work such as Category:Early replicas of Mona Lisa, or the display of a very prominent work in a location where it only temporarily resided, such as Category:Mona Lisa at the National Gallery of Art. -- Jmabel ! talk 15:35, 11 September 2014 (UTC)
Hello Jmabel, thank you for your answer. I had read a little bit here also, I will now proceed as you have written. Regards --Jean11 (talk) 16:31, 11 September 2014 (UTC)
Checkmark This section is resolved and can be archived. If you disagree, replace this template with your comment. Jmabel ! talk 23:12, 11 September 2014 (UTC)

September 12Edit

Media Viewer Consultation ResultsEdit

Screenshot of the Media Viewer's new design prototype

Thanks to all contributors who participated in the recent Media Viewer Consultation!

The Wikimedia Foundation's Multimedia team appreciates the many constructive suggestions to improve the viewing experience for readers and casual editors on Wikimedia projects. We reviewed about 130 community suggestions and prioritized a number of important development tasks for the next release of this feature. Those prioritized tasks have now been added to the improvements list on the consultation page.

We have already started development on the most critical ('must-have') improvements suggested by the community and validated through user testing (see research findings and design prototype). We plan to complete all “must have” improvements by the end of October and deploy them incrementally, starting this week. See the multimedia team's improvements plan and development planning site for details.

As we release these improvements, we will post regular updates on the Media Viewer talk page. We invite you to review these improvements and share your feedback there.

The foundation is also launching a file metadata cleanup drive to add machine-readable attributions and licenses on files lack them. This will lay the groundwork for the structured data partnership with the Wikidata team, to enable better search and re-use of media in our projects and many other features. We encourage everyone to join these efforts.

This community consultation was very productive for us and we look forward to more collaborations in the future. Thanks again to all our gracious contributors! Fabrice Florin (WMF) (talk) 01:08, 12 September 2014 (UTC)

@Fabrice Florin (WMF): Where exactly have people asked for the removal of metadata in your consultation? I found one comment opposing this change and none in favour of it, and I don't think removing features is a good way to improve the popularity of a product … If you want more people to go to filedesc pages, remove the MV, but if you want to improve the media viewing experience, don't remove features from your viewing product.    FDMS  4    01:55, 12 September 2014 (UTC)
@FDMS4: If people want the metadata, they should come to the file page on Commons. MV should not be a replacement for visits to Commons. That is a message the Multimedia team have had loud and clear from a lot of the community, not least at Wikimania. That's why MV will be much more focussed as a different way principally to view the information on the Wikipedia page, with a big blue "More details" button that will bring people straight to Commons. For Commons, the simplification of MV, and reduction of metadata provided, is a good thing. As well as giving users a simpler, more focussed initial experience. Jheald (talk) 07:31, 12 September 2014 (UTC)
@Jheald: Thanks for jumping in. Totally agree. I think we should revisit a more comprehensive expanded viewer when we can do editing of metadata right in the viewer (for which proper structured data underneath is a prerequisite). Otherwise it's appropriate for the File: page to be primary and any expanded info to be minimal, so that readers learn about the File: page as a place to not only find the advanced info, but also possibly curate/edit.--Erik Moeller (WMF) (talk) 08:17, 12 September 2014 (UTC)
@Jheald: "MV should not be a replacement for visits to Commons." What should it be then? I'm using a Mac with a trackpad, I don't need a media viewer to enlarge images. Yes, being able to view files and metadata from projects like the English Wikipedia reduces Commons traffic. However, if traffic is all we care about, we should probably stop using free licenses as they encourage copying and transferring. I personally don't think that traffic is more important than the usability of our user interface, and the financing of Commons fortunately does not depend on traffic. There was a very loud and clear message from the community, namely we don't want the Media Viewer. It should not come as a surprise that large parts of the community, often having very strong feelings about this product, would welcome any removal of features. The WMF has decided not to listen to these parts of the community, and instead start a process to find out what the actual users think about their product. Also unsurprisingly, none of the actual users said remove features from it. Now, probably because of the superprotect fiasco, it has been decided to fulfill one wish of the angry croud perceived as important, and do exactly that. The full description and date of creation are essential information, the MV could as well only display a low-res version of the image – imagine how much Commons would profit from that.
@Erik Moeller (WMF): "I think we should revisit a more comprehensive expanded viewer when we can do editing of metadata right in the viewer […]." Are you aware that it isn't currently possible to edit metadata right on the file description pages either? If you wanted metadata to be modifiable in the Media Viewer, why didn't you just add [edit] links? Also, if you want to encourage the curation of files, why does the prototype make exactly that even harder? Yes, there are tools on filedesc pages that can't be made available in the MV. However, using the current MV, I was able to detect metadata with errors (typos in decriptions, wrong date formats, overcats, …) and fix them.    FDMS  4    22:11, 14 September 2014 (UTC)
The prototype is better than the current version :) --Steinsplitter (talk) 15:17, 12 September 2014 (UTC)

Can we please make Media Viewer opt-in only, especially on Commons? On commons it really serves no purpose at all since you are already on commons. I appreciate that it has been removed for logged in users, but I am not always logged in and find it extremely annoying to click on an image to get to that file and instead have the media viewer pop up. I note that the result of the RFC on EN was to make it opt-in only. Delphi234 (talk) 20:45, 12 September 2014 (UTC)

This appears to have been implemented now. Very good. Or was Media Viewer completely deleted from commons? Delphi234 (talk) 18:57, 14 September 2014 (UTC)

Per Fabrice's comments earlier. MediaViewer was set to opt-in for only logged in users on about august 20 [4]. Logged out users still have the feature enabled. Bawolff (talk) 19:20, 14 September 2014 (UTC)
I spoke too soon. I may have had javascript shut off when I thought it was not being used. It is still here for IP users. Delphi234 (talk) 21:06, 16 September 2014 (UTC)

Duplicate content warning is brokenEdit

I'm trying to find an image of the Mk. VIIIB radar which I found on the IWM. I suspect Fae already uploaded it, but as always all attempts to find the file have failed. To put that in perspective, searching for "village pump" with all options turned on also fails.

Anyhoo, I uploaded the image myself and received this error:

There is <a href="#">another file</a> already on the site with the same content.

Not useful! Can someone get that link working properly? And while they're at it, maybe make the text itself have the file name in it?

Maury Markowitz (talk) 11:22, 12 September 2014 (UTC)

Drop your file to FileAnalyzer or use Special:Upload to see the existing file. As for the broken message, this is bug 70639. -- Rillke(q?) 12:13, 12 September 2014 (UTC)

Image generation brokenEdit

For each of our images (e.g., File:Old Pier, Salen, Isle of Mull.jpg) one can ask MediaWiki to generate an image of any size. This is used for the preview image on the image-description-page as well as the "other sizes" options. What may be little-known is that the "1280px" in that URL is actually a parameter to the resizing code and can be anything you like. See User talk:Dschwen#Image viewing tool for FP for details. But when playing with this again today, I find it is broken for large sizes. For example 5727px works but 5728px fails. For another image 3435px works but 3437px fails. Has something in the software changed to impose limits? I was hoping someone (e.g. Dschwen) might be able to generate a template that does the maths to scale any image to a given megapixels, thus making it easy to offer an image sized for review which still having the option to upload an original-sized version. Who would know more about this? -- Colin (talk) 12:51, 12 September 2014 (UTC)

@Colin: If you just want to build a URL you will be better off with using Special:Redirect. Of course someone still has to do the math, if a fixed width or height is not acceptable. I don't think this can be done in a template though, as it would require an API call to get the image dimensions. --Dschwen (talk) 19:30, 12 September 2014 (UTC)
This isn't a new limit, just doesn't come up very often in terms of result image size. There is a limit that image scaling can only take at most 400 MB of RAM (If that's exceeded, it generates error code 137 [137 = 128+9. 9 = SIGKILL]). In order to scale an image, generally the image scaling program needs enough ram to have the result image fully decompressed in RAM, sometimes have the source image fully decompressed (Whether or not that's needed depends on the image format. non-progressive JPEG only needs about as much of the source loaded as the size of the result [AFAIK], and PNG (when using VIPS) generally do not need source loaded), plus some general overhead. The bigger the resulting thumbnail, the more memory it will use. Bawolff (talk) 14:08, 13 September 2014 (UTC)
Bawolff, thanks for the info, but something has changed because the examples I gave on Dschen's talk page all used to work when I wrote that message. And the File:Old Pier, Salen, Isle of Mull.jpg is only an 8MB JPG (and 110MB uncompressed) so shouldn't hit the 400MB limit. So I wonder if some coding change has meant less efficient use of memory or perhaps higher than 8-bit colour for some intermediate stage. It is becoming more important to be able to deal with and specify large JPGs at less than 100% resolution because 100% detail is seldom flattering and often too much. On Dschen's talk page, I indicated it would be wonderful if the image description page offered more choices for reduced-size versions: relative (25%, 50%, 75%) and megapixel (2MP, 4MP, 8MP, 16MP, 24MP, 36MP). The current size options max out at 0.7MP, the size of a small monitor bought 10 years ago. Whereas many of us are viewing on screens 2, 3 or 4 times that width/height. -- Colin (talk) 11:31, 15 September 2014 (UTC)
I'm not aware of any recent changes to the relavent config. I believe image magick is compiled to use 16 bit colour internally (Q16 option), but its always been that way. There's plans to update the OS on those servers soon-ish, but I don't think that has happened yet. Bawolff (talk) 00:18, 16 September 2014 (UTC)

Which template?Edit

I checked the license of File:Wire Loop Game.jpg and confirmed it is fine. However, while I see a lot of Flickr related templates, I do not recall which one I use in this situation.--Sphilbrick (talk) 14:19, 12 September 2014 (UTC)

✓ Done?    FDMS  4    15:09, 12 September 2014 (UTC)
I don't think so. I vaguely recall seeing some images with a template, stating that reviewer X has reviewed the license at Flickr, and confirmed it is OK. I believe there is also a bot that does this, but I thought there was a template for a manual review.--Sphilbrick (talk) 15:52, 12 September 2014 (UTC)
It is the template on the page and that FDMS4 parametered as OK. -- Asclepias (talk) 17:52, 12 September 2014 (UTC)
For example {{FlickreviewR}} is similar, but to be used if the license is not the right one. There must be one to use when it is OK. --Sphilbrick (talk) 15:55, 12 September 2014 (UTC)
See Commons:License_review#Instructions_for_reviewers, please use User:Rillke/LicenseReview.js for manual reviews, the other script seems outdated. For Flickr images it's best to wait for the Bot because it also has some extra functions like uploading the highest res version. --Denniss (talk) 17:29, 12 September 2014 (UTC)
@Denniss: What is outdated about ZooFari's script?    FDMS  4    18:46, 12 September 2014 (UTC)
OK, I'll wait for the bot.--Sphilbrick (talk) 19:04, 12 September 2014 (UTC)
Never mind, I see that the bot has not been by. It hadn't when I first asked. I was concerned about th eopen OTRS template, so I'll just remove it.--Sphilbrick (talk) 19:06, 12 September 2014 (UTC)
Zoofari's script was last updated 2011 so it may lack some of the functions available in Rillke's script. --Denniss (talk) 19:21, 12 September 2014 (UTC)

"Naturalis license" ?Edit

Howdy,

May I run something by you? In the past year I've been visiting in the entomological collection of the natural history museum "Naturalis" in Leiden, Netherlands to research collection specimen and also to shoot images of these. The museum made me sign an agreement that states that I'm obliged to credit the museum for the usage of their collection whenever work resulting from this is published. As such I can only make the images from these sessions available under a special license form that includes this limitation. Here is an example. This would be very similar to selecting a CC-BY license using the museum as "author" but not quite the same. It would not be correct to name the museum as the author as they didn't create the images. For my part, I couldn't care less, my images are CC0/PD anyway, but it may not be fair to have the museum associated with the quality level of the images or some such. Anyway, it would surely be best to not abuse some existing license for this purpose but to simply indicate properly and truthfully what the license limitations are. Also, more authors working in the collection may have this problem and some may wish to make their images available under some other license (GFDL, or CC-BY-SA or some such) with the additional limitation of requiring credits for the usage of the collection. So what we would be looking at is a a set of licenses/templates to indicate this additional requirement such as:

Usage of this image requires that Naturalis always be credited for the usage of their collection

(or some other wording) Note: Although I'm not totally convinced, on principle, that the museum would have full legal rights to claim this requirement (it being largely government funded and all that), that is not the path I want to follow. If this is what they want, I'm happy to comply. Questions:

  • Is this something wikikmedia commons can live with (is it compatible with what we aim to do here)?
  • Would it require a full-fledged new license system with long legalese, or will a simple template do?
  • I'm pretty much "done" worrying about and discussing policies and templates on wikimedia projects, so I would be happy to supply images and keep doing so after future visits, but it would require help from the policy and template gurus here to set it up.

Your thoughts on this please :o) Cheers Pudding4brains (talk) 17:55, 12 September 2014 (UTC)

My suggestions: Don't try to reinvent the wheel. Don't try to mix different licenses, or a CC-0 declaration with an attribution obligation, or any other attempt at creatively making compatible stuff that is normally not compatible. it will just totally confuse the potential reusers. To me, it seems what you want to do is exactly what a CC-by license can do, with an attribution that you will word to say exactly what you want to say. In the attribution under CC-by, you don't have to credit yourself if you don't want to and you don't have to present the museum as being the author of the photograph. You can write that attribution to say anything you want. The only thing that you are requiring with the CC-by is the presence of that credit, for example something like "Specimens of the Naturalis biodiversity center, Leiden", or "This image uses specimens of the Naturalis biodiversity center, Leiden", or "Specimens photographed at the Naturalis biodiversity center, Leiden" or whatever wording you want and you think will make the museum happy and is short enough to be easily reusable. -- Asclepias (talk) 18:27, 12 September 2014 (UTC)
Museums often sell postcards or books including copies of their images, and while the collection and card is protected, the images that it contains are not, but retain the copyright status of each image. While you are contractually bound by your agreement to provide attribution where ever you use the image, no one else who uses that image is. I would recommend noting in the description that the image is from the Museum, yourself, but I do not see how anyone can be constrained to include that description who sees it and uses it - other than the fact that it is very helpful to know where the work actually exists, but where it exists is not a part of any copyright, as far as I can tell. Delphi234 (talk) 21:22, 12 September 2014 (UTC)
My understanding of the question was that the photographer wants to require that the mention of the museum be retained when the image is reused, and is looking for a way to actually require only that, while not requiring anything else. He should be able to do that with a license. The obligation of the reuser of the licensed photograph is to the photographer, not to the museum, and the photographer would probably not be interested to sue a reuser who would not include the credit to the museum, but still, the principle remains that if the license from the photographer requires mentioning the museum, then in theory reusers should include that mention. (We know that many reusers ignore the licenses anyway, but that's a different matter). -- Asclepias (talk) 23:20, 12 September 2014 (UTC)
Agree with Asclepias. Adding an "institution" template as used here will help to highlight the museum from which the specimen is coming. Jee 02:08, 13 September 2014 (UTC)
Okay folks, thanks for all the replies. I've now (quick&dirty) done this with it: File:Puncha_ratzeburgi_aberrations_-_collection_Naturalis.jpg.
The license terms (non human readable) seem to indicate that if the name of the author is supplied that it must be included in the attribution. This is not what I want, so the only way around that is not supplying an author name (or pseudo), which is actually technically and policy-wise impossible here, as WC requires me to truthfully state that it is my own work. So the solution is not "elegant".
The supposedly free licenses, be it GFDL or Creative Commons, make it near impossible to do anything useful with the work released under those licenses. If you care to do exactly as the license requires that is. Which is exactly why all my work is PD/CC0. All the attribution, linking, license mentioning etc etc would make it totally impossible to create a collage such as the example here if you would care to do so from CC-licensed work by others (not your own images). I was looking at creating my own template, using some cc-by icon, but the as the icon is licensed under a more severe license (cc-by-sa) than what it even stands for, I would need to include all sorts of bullocks for that license on the page just to be able to use the icon to indicate some other license. GFDL and CC licensing sucks big time. Sorry for the rant ;o)
If anyone feels I should handle things differently, be it due to policy/lagal issues or efficiency or whatever, pleas let me know.
Thanks and all that :o) Cheers, Pudding4brains (talk) 03:18, 13 September 2014 (UTC)

September 14Edit

usage of KML scriptEdit

I have copied and pasted two kml scripts in a personal test area. (User talk:Smiley.toerist/test area kml files)

  • How can these underlying kml files used in google maps links in Wikipedia articles be activated and maintained?
  • Can the google map link in the scripts be replaced with a more general script wherby the reader has the choice to activate other background maps such as Openstreetmaps. The same as used for Geocoordinates?Smiley.toerist (talk) 10:35, 14 September 2014 (UTC)
Something like that exists on en.wp: en:Template:Attached KML. You have to upload the files locally though. And I don;t know if any projects besides en.wp support this. --Dschwen (talk) 20:18, 14 September 2014 (UTC)
Looks like I would have to adapt the kml script to deploy on other background maps than google maps. (xmlns= ....) It looks wastefull to apply the template to only one language wp, as it can be used in any wp. Smiley.toerist (talk) 14:40, 15 September 2014 (UTC)

September 15Edit

Custom license markerEdit

Hi. I noticed that {{Custom license marker}} is on many files but what is it good for? Anyone know? --MGA73 (talk) 05:19, 15 September 2014 (UTC)

Yup, I've often wondered too. Some knowledgeable person ought to prepare documentation explaining its purpose. — Cheers, JackLee talk 18:02, 15 September 2014 (UTC)
Same as above. Pinging Saibo who created the template, on the unlikely chance he still visits from time to time. Huntster (t @ c) 03:13, 16 September 2014 (UTC)

Licensed-PD-ArtEdit

If GFDL is used in {{Licensed-PD-Art}} then the files end up in Category:License migration candidates. Perhaps someone know how to fix the template so that license migration is possible. I tried to copy and modify some of the code from {{self}} but id did not work for me. Thank you. --MGA73 (talk) 05:48, 15 September 2014 (UTC)

Colourising and replacing imagesEdit

I'm alarmed to see that some colleagues, notably as part of en:Wikipedia:Graphics Lab/Photography workshop, are colourising b&w images and overwriting the original. Recent examples are File:King Luarsab II of Kartli.jpg, File:King Archil.jpg and File:Chavchavadze 31-155 s.jpg (in the latter case, the b&w version already replaced a different image). The b&w originals are often historic documents. Overwrting them replaces the original on all projects and external sites that transclude them. Can we agree a clear policy that this is not to be done, and that colourised versions must be uploaded as new files, not overwriting the original? An example of such good practice is File:Sabinin. St George the Hagiorite colourised.jpg. Andy Mabbett (talk) 12:24, 15 September 2014 (UTC)

There is nothing wrong about colorizing old photos (if it looks good, at least), as long as in the file description it's clearly said that it's a modern colorized photo. Having said, the original photo should never be replaced by the new colorized photo. The colorized photo must be uploaded into a new file. --Lecen (talk) 12:48, 15 September 2014 (UTC)
While I agree with Andy Mabbett that these colorizations should be reuplaoded as new files and reverted, one thing makes this much less of a scandal than I first thought: These 1st two images are both derivatives — extracted / cropped off from an original that has been properly kept. (Not the case of File:Chavchavadze 31-155 s.jpg, whose file history shows three items which should all be reuploaded separately.) -- Tuválkin 13:27, 15 September 2014 (UTC)
There is everything wrong with colourising old photographs. It misrepresents history. There is no purpose served by creating colourised photographs of, say, Abraham Lincoln. It provides no useful information and misrepresents the image. As for the Luarsab II/ Archil of Kakheti etc images, yes, the engravings are derivatives from the original medieval works, but they are also historical works in their own right. Colourising them creates the impression that they are chromolithographs, which is very misleading. There needs to be some clear thinking about this. Are we going to create colourised film stills for b+w films? I hope not. It's one thing to represent the fact that a film, such as Casablanca, for example, has been colourised. It's another thing to create such images. The same applies to photographs. I can see no justification for the creation of this unspeakable thing: File:Mary Eristavi (crop) colorized.jpg or its new friend File:Mary Eristavi (color2).png. Compare them to the beautiful original photo File:Mary Eristavi (crop).jpg. Paul Barlow (talk) 13:40, 15 September 2014 (UTC)
I see no problem with it, porovided that the original image is still available (no overwriting it); the image is here to illustrate someone/sopmething where ther color is present (as opposed to a PD image uploaded to represent itself); and the description page states clearly that the image was colorized. Abraham Lincoln wasn'r black-and-white, and a colorized image of him would presumably look more like he did than a blackj-and-white image. A film still would be here to represent the film; if the film was black-and-white, then the colorized image would not be a better representation of the film. עוד מישהו Od Mishehu 15:22, 15 September 2014 (UTC)
I've no idea what you mean by "the image is here to illustrate someone/sopmething where ther color is present". In many cases it does not illustrate anything but the fantasy of the colouriser. To say that the real Abraham Lincoln existed in colour is to wholly misunderstand the nature of images and what we get from them. There are two issues. One is that image is represented for what it is: a historical photograph, engraving or whatever. The other is that is does not represent something that is either useless, or potentially false. The editor who made File:Mary Eristavi (color2).png made up the colours. These images appear on google searches. Paul Barlow (talk) 15:36, 15 September 2014 (UTC)
The colorized image is not a historical photograph; it is an artist's impression closely based off a historical photograph.--Prosfilaes (talk) 21:43, 16 September 2014 (UTC)
Limiting myself to the actual question posed; Colourised images should never overwrite an original. The only potential exception I can think of is when the original was only uploaded in order to ask for a colourisation of it. I believe a discussion of the merits of colourisation itself is being discussed elsethread. Hohum (talk) 17:39, 15 September 2014 (UTC)
You refer to discussion on en.WP about the use of colourised images in its articles; it's not relevant here, because each project can set its own policy. Andy Mabbett (talk) 18:56, 15 September 2014 (UTC)
Never mind what’s being discussed in w:en — this thread is about overwriting colorized images over their b/w originals, not the merits of colorization itself; if anything, Commons is way more permissive than Wikipedia when it comes to such matters, but feel free to open a thread about said merits here too. -- Tuválkin 19:43, 15 September 2014 (UTC)
Er, that's what I said: "it's not relevant here". Andy Mabbett (talk) 13:20, 16 September 2014 (UTC)

Because nobody mentioned it yet: There is a template ({{retouched picture}}) for that.    FDMS  4    18:53, 15 September 2014 (UTC)

Perhaps we need a more specific template, or parameter, and category, for colourised images? Andy Mabbett (talk) 18:54, 15 September 2014 (UTC)
Yes, please: We do need a kind of warning template for prospective users, saying something like «This color image was created from a monochrome original» (with a link to it), similar to {{personality}} and also to {{extracted}}. Simply saying it is a {{retouched picture}} is not enough — sometimes retouching is a mere cleanup of a dusty scan or a damaged photograph, while colorization is a derivative new work — its contents may be signficantly different and re-licensing may apply, too. -- Tuválkin 19:43, 15 September 2014 (UTC)
Re-licensing won't apply in the US; both the recent Copyright Office report and their report on the decision to register colorized movies make it clear they won't register colorized pictures.--Prosfilaes (talk) 20:41, 15 September 2014 (UTC)
Yes, I agree that a new template for colorized images would be helpful. MjolnirPants (talk) 20:51, 15 September 2014 (UTC)
 
I am the editor Pigsonthewing referred to in the OP. I uploaded colorized version over old images because I was asked to colorize those images, not to create separate, colored versions, and because I never gave a thought to the use of the image, only to the request itself. Despite the rather unproductive argument which ensued at en:Wikipedia:Graphics Lab/Photography workshop, I agree that a policy of always creating new files when an existing file is modified in such a way is a good thing to have. I can find no mention of such a policy already, and so I think that WP and commons would be best served by using this thread to arrive at such a policy. To that end, I propose the following:
  • Works of art should only be colorized when doing so is part of an effort to restore the image, not to improve the image.
  • When an image used to illustrate some subject is colorized, it should be uploaded as a separate file and labelled as a colorized version.
I think that a way of communication this policy needs to be implemented as well. There is a header at the photography workshop that could be modified to show this and any other policies governing alterations to images used on WP. The problem is most likely to be solved by working to ensure that everyone is on the same page, not by berating or making demands of other users. MjolnirPants (talk) 19:34, 15 September 2014 (UTC)
@MjolnirPants:: There already is Commons:Overwriting existing files. Might be enough to add this to the header of the graphics lab? --El Grafo (talk) 19:44, 15 September 2014 (UTC)
@El Grafo:, Yes, adding a link to that would be a good idea. I'm not sure it's enough, though. I still believe there should be a policy regarding colorizing files, and that all policies relevant to requests made there should be linked. MjolnirPants (talk) 19:51, 15 September 2014 (UTC)
You are not "the editor referred to in the OP", as I did not refer to a single editor, but to a trend among editors, plural. The argument on en.WP was unproductive, because in response to my polite request that you create new files when colourising, you told me to fix the issue myself. Andy Mabbett (talk) 13:20, 16 September 2014 (UTC)
If you intend to do nothing other than whine and complain, then please excuse yourself from this discussion. MjolnirPants (talk) 13:40, 17 September 2014 (UTC)

Andy is undoubtably correct about uploading colourized images separately. And the more I think on it the more I agree with Paul too. These images appear on Google searches, and some of them arguably have negative EV. Perhaps there should be an equivalent to en:Wikipedia:Featured picture criteria that deals with the poorest quality images/edits, so that they can be deleted/reverted by consensus? All too often, valid concerns about image edits (of all kinds) are seen as vitriolic by thin-skinned editors, and discussions descend into a prickly exchange in which uninvolved editors are unlikely to 'take sides'. It would be useful to be able to hand over the decision to another set of editors. Apologies if I'm drifting off topic. nagualdesign (talk) 21:13, 16 September 2014 (UTC)

We sometimes use paintings of people who were dead when they were painted, as well as hand-painted postcards of b&w photos. People respond very strongly to color, and it turns some of those dull splotches of grey or brown into something that would actually attract readers' eyes. Especially if some research is done, these images can be very valuable.--Prosfilaes (talk) 21:35, 16 September 2014 (UTC)
@Nagualdesign: I think your point about avoiding prickly discussions and side-taking is quite valid. It's unproductive to argue about the validity of certain edits. If, instead, we can reach a rough agreement on when such edits are appropriate, and a firm set of guidelines as to how they should be done, such discussions can -for the most part- be avoided in the future. Improper requests can be stopped before they are fulfilled and improper edits reverted without lengthy arguments if we can agree on standards which images must meet before being colorized, and standards which the colorized version must adhere to. That would be far better than a group of editors simply voicing complaints about certain edits without taking any steps to correct the problem. Note that despite the length of this thread, no-one has argued that overwriting images is an acceptable practice.
Also, you said "All too often, valid concerns about image edits (of all kinds) are seen as vitriolic by thin-skinned editors," I would like to point out that referring to edits as "abominations" and "unspeakable" is vitrolic, regardless of the thickness of one's skin. "The quality of this edit is quite poor," is a valid concern about an image edit, while "This is an abomination that should never happen!" is vitriol. MjolnirPants (talk) 13:40, 17 September 2014 (UTC)
I stand by my original statement. You seem to be cherry picking individual words to be offended by, regardless of context. "Personally, I think unspeakable images such as this should never happen at all" is a valid concern, and I would gladly second that opinion. And "Creating the coloured abomination serves no more purpose other than creating a coloured-in version of a Julia Margaret Cameron photograph" is equally valid, IMO. I see no vitriol.
The world is full of all sorts of different people with very different sensibilities. Some people can be terse, others polite, and you just have to find a way of getting on with different personalities. If you're going to 'spit the dummy' whenever anyone words something differently to how you would have preferred, perhaps a collaborative project isn't for you. And if you honestly believe that "appending "please" to a demand does not make it less of a demand" then you're on a hiding to nowhere. nagualdesign (talk) 18:48, 17 September 2014 (UTC)

bot work requestEdit

Hi, I need some categorizing work to be done by a bot. Whom and where can I ask for? Thanks sarang사랑 12:26, 15 September 2014 (UTC)

Commons:Bots/Work requests. -- Asclepias (talk) 13:22, 15 September 2014 (UTC)
Checkmark This section is resolved and can be archived. If you disagree, replace this template with your comment. Thanks Sarang

Flickr geotag requestEdit

File:Birds (3167198086).jpg was originally posted on Flickr with a cc-by-sa-2.0 license, but without any location data. I posted a request to the photographer asking for location data, which he has provided with geotags, but he at the same time changed the license to © all rights reserved. I've added Flickr-change-of-license tag to the pic, BUT . . . this license change also means I can no longer use the Flinfo tool to extract the geotags from Flickr. I can't find any other way for downloading the geotags from the Flickr file. Can anyone help, please? Thanks! - MPF (talk) 20:34, 15 September 2014 (UTC)

I don't see the problem. On that file page on Flickr I see a link to a map: https://www.flickr.com/map/?fLat=57.933034&fLon=34.276313&zl=13&everyone_nearby=1 – are these numbers (57.933034 and 34.276313) not the latitude and longitude that can be put verbatim into {{location dec}}? darkweasel94 20:52, 15 September 2014 (UTC)
Yes, that is the right location, thanks. For whatever reason, I don't have that link appearing in my browser - the map opens as an internal pop-up without the latitude and longitude figures visible.
Checkmark This section is resolved and can be archived. If you disagree, replace this template with your comment. MPF (talk) 21:36, 15 September 2014 (UTC)

September 16Edit

File:Angel's Logo.pngEdit

I am not sure if the copyright rationale given for the File:Angel's Logo.png is correct. The uploader is claiming that they are the copyright holder, but the url address listed in the image leads to this page which is apparantly copyrighted by "Angel Sessions". The image appears to come from this page. I guess the uploader could either be Angel Sessions or her representative, but the same uploader has also uploaded quite a few other files, all of which have be flagged for deletion or some other problems. To me, it looks like this logo was taken from the aforementioned website and uploaded to commons entirely in good faith, but inappropriately as "own work". I am solely basing this assumption on the fact that all of the other files uploaded by this user, including File:Twitter-50x50.png, File:Facebook-50x50.png and File:Linkedin-50x50.png, have been uploaded using the same "own work" claim. - Marchjuly (talk) 04:40, 16 September 2014 (UTC)

Thanks for reporting, Marchjuly. I've filed a deletion request. --El Grafo (talk) 19:39, 17 September 2014 (UTC)

1.700 videos addedEdit

Johann Strauss arriving in Amsterdam (1931)
War vessel HMS Bristol in the port of Amsterdam (1973)

Hi all, At the Netherlands Institute for Sound and Vision we have in recent weeks uploaded another 1.700 videos of Dutch news reels from roughly the '20s until the '70s of the 20th century. Even though the more recent items contain Dutch commentary (and at present no subtitles are available) there is also a considerable amount of silent footage which could very well be used on other Wikipedia language versions. For some items English metadata is already available. We would highly appreciate the use of these items in articles on Wikipedia, also to 'scale' the discussion about the role of video on Wikipedia in general. Only 0.12% of all articles on enwiki contain videos! And with nearly 4000 video's on Commons, the Netherlands Institute for Sound and Vision provides 8% of all video on the platform. Even though we are pleased to be the largest provider, we also acknowledge that this is mainly due to the fact that there is so very little video being offered on Commons. It was the videoonwikipedia.com initiative that stated: "Motion! Videos can explain, clarify, and engage like nothing else." I hope that when Wikipedians use this collection they can illustrate this point and inspire other audio-visual archives and producers of video to, where possible, make their material available on Commons. 85jesse (talk) 07:54, 16 September 2014 (UTC)

Great to have all these videos in Commons, but this is the one wrong place to call for their use in other projects — you need to tell that in those projects’ VPs and WCs and other such generic discussion boards. What Commoners must do is to categorize our video, so that it is easy to find by people reseraching media items for any given subject. Lets do that! (Althogh categorizing video and audio is way more time consuming than images.) -- Tuválkin 19:10, 16 September 2014 (UTC)

WatermarkEdit

We received an "informal" opinion on Removal of watermarks from Commons images from the WMF legal team. (see the notification above.) We discussed this matter at Commons_talk:Watermarks#m:Wikilegal.2FRemoval_of_watermarks_from_Commons_images and most people suggested that we must stop encouraging/advising people to remove watermark until we get a different opinion from the legal. Currently two of our templates are not only advising people to remove watermarks, they state doing it is fully legal. This is directly contradicting with the opinion of the legal. So we need to take immediate measure to either stop the use or rewording of these templates. See the discussion. Please keep all the comments on that DR. (as a single place) Jee 12:55, 16 September 2014 (UTC)

Wikidata property for Commons Creator templatesEdit

The wikidata:Property:P1472 may now be used to add details of a person's "Creator" template to their Wikidata biography. Andy Mabbett (talk) 18:01, 16 September 2014 (UTC)

Thanks, Andy!
Note that this new property should always be used instead of direct sitelinks to the Creator template. A list of Wikidata items (currently 5) that do contain direct sitelinks to Creator templates can be found at d:Wikidata:WikiProject Structured Data for Commons/Phase 1 progress/Links/Creator, together with links to SQL queries that anyone can run to produce updated lists. Jheald (talk) 13:16, 17 September 2014 (UTC)

September 17Edit

upload a page to wikepediaEdit

How can I upload a profile to wikepedia? — Preceding unsigned comment added by Bigmick98 (talk • contribs) 02:30, 18 September 2014‎ (UTC)

This is the Wikimedia Commons, not the English Wikipedia. If you are interested in creating a new article on the English Wikipedia, a good place to ask for help would be w:Wikipedia:Articles for creation. — Cheers, JackLee talk 19:52, 17 September 2014 (UTC)

Cats for photos of unnotable wikimediansEdit

Are categories of wikimedians shown on photo ok per PS and so on? I mean of those who are not notable to have a Wikipedia/Wikiquote article about them. We've got plenties of photos with users from wikimeet-ups, wikicons, even wikiexpeditions (thought users are supposed to make photos of objects but not themselves in the latter) - I think they should have cats like Category:Photos showing User:Example or just Category:Photos of User:Example. I've seen such IIRC but are they really allowed? If yep then it's work to be done to fill them :) --BaseSat (talk) 19:16, 17 September 2014 (UTC)