Wikimedia Commons

Commons:Village pump/Archive/2019/12

< Commons:Village pump‎ | Archive

How do I find images to rotate?

Hello, everybody. I would like to contribute more to Commons. I had seen the Rotate template and the corresponding category. But I see that there is not much work to be done and apparently some files are not categorized. How can I find images that need to be rotated? --Hispano76 (talk) 01:51, 1 December 2019 (UTC)

@Hispano76: If they haven't been put in Category:Images requiring rotation by a user applying {{Rotate}} to them, I doubt there is a quick way to find them. It's not something that can be searched for or determined automatically. There are some other categories that require similar attention from someone with a bit of image-editing knowledge such as Category:Images with borders and Category:Images requiring extraction that you could check out. – BMacZero (🗩) 07:04, 1 December 2019 (UTC)
@BMacZero: Okay, thank you. I'll check the categories and see what I can do to help. Greetings. --Hispano76 (talk) 19:15, 1 December 2019 (UTC)

Light effects

 

I have dificulty of getting the correct definitions. Stricty speaking these are not reflections, but reflected light over a wavy water surface. Can this be defined as 'projection'? Smiley.toerist (talk) 23:38, 1 December 2019 (UTC)

Files with dubious sources

As a licence reviewer, my job is to check whether a photo is under a suitable licence, and more importantly whether that licence has been issued by the genuine author. As such, when the licensing party does not match the author, and there is no concrete evidence of proper authorisation, I would fail the files.

However, recently Srittau (talk · contribs) were closing DRs of flickr files from dubious sources because he insisted "If you believe the Flickr uploader incorrectly licensed the photos, contact them and ask them to change the license on Flickr first."

  1. Commons:Deletion requests/Files found with "Pierre Holtz"
  2. Commons:Deletion requests/Files found with Eickhout

I raised this problem on his talk page and Commons:Administrators'_noticeboard/User_problems/Archive_81#Second_incident, but he could not offer any reason why such files could be accepted despite lack of proper licences from the true authors. I believe these closures were contradictory to the Precautionary principle and Commons:Project scope/Evidence.

The community's view on this matter would be very helpful for clarifying what is or is not accepted.--Roy17 (talk) 02:04, 1 December 2019 (UTC)

This problem has be to addressed, because it makes reviewing files impossible to proceed. For example, I was just gonna fail File:The Someone Great Cast Play Our Real Or Fake Cocktail Game - MTV Movies.webm, because it has movie clips, which I dont believe MTV has the rights to release as cc-by, but by Srittau's logic, there would be no problem and someone should contact MTV before they DR here.--Roy17 (talk) 02:08, 1 December 2019 (UTC)
Strawman argument. Completely different circumstances. Sebari – aka Srittau (talk) 22:47, 1 December 2019 (UTC)
I am sorry if my response is terse, but after two DRs, a discussion on my talk page, a AN/U complaint, with no new arguments, but where I was explaining my rationale and gave a way forward (contact the Flickr uploader or the photographer) my patience is growing seriously thin. Sebari – aka Srittau (talk) 09:33, 2 December 2019 (UTC)

Problem when uploading videos

I uploaded videos yesterday, but for some resolutions, transcoding always fails. If we look at the videos uploaded in recent days, they all seem to have missing resolutions, since transcoding has failed. Okki (talk) 06:49, 2 December 2019 (UTC)

You can take a look at the last few days on this page. For exemple, File:2019-12-01 forge-musee-Etueffont.webm / File:Museum and wiki 2019 part1.webm / File:2019 Rostelecom Cup - Alexandra Trusova FS.webm / File:Rede bei FFF-Demo Hof (Michaeliskirche; UHD-1 60 FPS) 20191129.webm... For my three videos, it took me several hours and a lot of uses of the Reset transcode feature to finally get all the resolutions. Okki (talk) 19:29, 2 December 2019 (UTC)

Shortcut for upload in specific category

Hi, every time I have to introduce a newbie to an upload, it takes me some time to explain the category systems. I don't mind per se to correct/improve those upload later (as it's the case 99% of the time) and I don't mind to teach but in some dense moment it would really help to have some shortcut.

For example I need some images of an award ceremony for a press release and explaining in the third mail or message this morning how to upload and insert the category that I have prepared is really time consuming. If they don't understand, I won't have my images ready for the press release and news expire soon. if I don't know their exact usernames, I won't find the uploaded files easily and have to sent more mails trying to know it.

Is there a way, simpler than organizing an upload interface such as those in the competitions, to send a url to the newbie of the Upload Wizard that automatically include information about a specific category? Is there at least a preference to make a shortcut appear on the left bar when you open an category?

Thanks.--Alexmar983 (talk) 10:29, 2 December 2019 (UTC)

@Alexmar983: There is Commons:Upload Wizard/Fields prefilling − you can share a link that has the category pre-set. Would that work for you? Jean-Fred (talk) 18:39, 2 December 2019 (UTC)
Jean-Fred yes! Too late for this time but perfect for the future. Finally!--Alexmar983 (talk) 18:42, 2 December 2019 (UTC)

Tools for fighting "structured data" vandalism

What are the simple to use recommended processes for fighting vandalism that does not appear in standard wikitext like this? Thanks --Fæ (talk) 11:08, 1 December 2019 (UTC)

That's one of the problems with not doing a proper Threat/Defence analysis on software, you permit hard-to-detect problems. A good step forward would be a pop-up watchlist preview of captions. Otherwise, I don't think there's a simple way other than a filter that detects caption edits by new accounts, but most of these seem to be added by new(ish) users anyway. I would see a permission for "Caption Editor" as being heavy-handed and contrary to the openness of a Wiki. Rodhullandemu (talk) 11:19, 1 December 2019 (UTC)
Genuinely I was not sure if the "experimental" introduction of structured data at the beginning of this year had been backed up by system changes that make more sense for copyright and vandalism protection. It's sad to see that nothing has been done in the rush to forcing structured data on Commons regardless of impact.
I believe it's time to have a proposal and vote to at least change the standard Wikimedia Commons upload wizard so that newbies are not effectively forced to type so-called "captions" as structured data entries, rather than the work flow being to add useful and searchable "descriptions" into the not-structured data description field which will actually be searchable as it is added to the standard wikitext. If there's no conflict with other initiatives, should I go ahead and make that proposal so that we can "force" a task for the WMF on Phabricator so the upload wizard prioritizes meaningful wikitext rather than captions which are not searchable? --Fæ (talk) 11:41, 1 December 2019 (UTC)
Yes, I think you should go ahead.--Ymblanter (talk) 11:57, 1 December 2019 (UTC)
+1. TBH, I don't really like SD. Masum Reza📞 14:57, 1 December 2019 (UTC)
  Support If only they'd understood how we work here, they'd have avoided a lot of criticism. Rodhullandemu (talk) 19:18, 1 December 2019 (UTC)
Yes, I also think you should go on. The structured data field is confusing in the upload wizzard. I can imagine that people just fill something in as it looks like that you have to fill something in. Wouter (talk) 21:11, 1 December 2019 (UTC)
Fæ, that's easy vandalism. It's obvious. I'm waiting for vandals to exploit phab:T235329. I guess they probably already do, but.. no way to find them. I'd like to contribute to a proposal if you are writing one. I even think "captions" as a whole are utterly stupid. Captions depend on context. Media legends on Wikidata (which get used as captions on for example eswiki) make sense because those captions are in the context of that Wikidata item. A "general" caption makes no sense because there is no context. What would make sense (but my suggestion for that was pretty much ignored) would be to transform captions into "alts". The alternative text to show when the browser can't load the image due to technical restrictions or because the page is being viewed by someone who is visually impaired. Because that description won't change much, regardless of context. But captions... sounded like something for the cool kids or whatever? I have no fucking clue. None whatsoever. - Alexis Jazz ping plz 21:45, 1 December 2019 (UTC)

Question: What's the actual issue here in terms of captions [For the non-caption SD, I do agree that better edit summary that shows what the Q numbers are for, would be nice, but the original complaint was about captions not the other SD stuff]? As far as I can tell, the revert button works, such edits show up in recentchanges, watchlist, etc. I'll be honest, I haven't really used the feature, and I also don't really do antivandalism patrol on commons, but at first glance it seems to tie into all the usual anti-vandalism features that normal wikitext ties into. Note: On the subject of searchability, captions seem searchable. For example [1] - the matching result only has the search terms in the structured data caption, and not the wikitext. Bawolff (talk) 09:23, 2 December 2019 (UTC)

The first example was not showing up in my searches, despite it being the most recent version of the image page. If that's a bug, super. However I cannot edit captions using wikitext, nor are they visible to tools like pywikibot when pulling the commons page, hellfire, we cannot even pull this information by SQL queries on the commonswiki underpinning database, simply ghastly and confusing implementation.
The key problem here is that newbies are being driven to enter captions, rather than descriptions. Plainly that is wrong, misleading and makes handling childish vandalism and "testing" from mobile devices harder to deal with. The community never agreed for the weird "captions" field to be the first big entry on the upload wizard. A RFC by the community should be able to reverse that decision and is necessary because the WMF is unwilling to take any action in response this type of feedback which is not 100% supportive of its Wikidata and Structured Data strategies that, apparently, do not require community agreement to be implemented live without credible assessment of negative impact. --Fæ (talk) 12:17, 2 December 2019 (UTC)
In fairness, you cannot query wikitext from tool labs sql replicas either (Since both normal wikitext/SD is stored in the same place which isn't available) - so structured data has parity with wikitext there. I guess pywikipediabot will need to have some time to catch up. The commons structured data is accessible via the mediawiki api, but in a slightly different way than normal wikitext (different slot). I agree that "caption" is a bit of a weird phrasing, for what afaict is just description but in a different place, but naming things is hard and they probably wanted to differentiate from the existing "description" so as to avoid confusing with the new thing. Changing something's name is also really easy technically (albeit sometimes not politically). Bawolff (talk) 18:59, 2 December 2019 (UTC)
@Bawolff: no, they really wanted "captions", but seemed to have little clue about what a caption is. It was just the first thing that came to their mind when they thought of structured data for files. And fixed captions for an image are really stupid. Also completely unusable because they can't contain wikitext. See Commons talk:File captions#Best practices? for me having fun with that and suggestions. - Alexis Jazz ping plz 20:39, 2 December 2019 (UTC)
@Alexis Jazz: Perhaps this is a pointy suggestion, but for the admins at commons, it is a wiki ;). That said, can't say i disagree, that the limitations on "captions", both length and lack of links don't seem very well motivated (Not really clear if this is even a technical restriction, or an intentional restriction). Bawolff (talk) 04:05, 3 December 2019 (UTC)

Regarding “Captions are not searchable”, not sure we are talking about the same thing − per Commons:File_captions#How_can_I_search_by_caption? they are. As a test, to confirm it, I just added the French caption “Église Old Søgne” to File:Sögne Old Church 85037 Apostles 12.jpg (which does not have a French wikitext-description), and a moment later or so it appeared in Special:Search/"Église Old Søgne". Jean-Fred (talk) 18:37, 2 December 2019 (UTC)

Just as a reminder that this problem is real: today GMG orange (talk · contribs) in less than 1 hour added to the structured-data fields of > 50 different image-files the completely image-unrelated words "human vagina" (in German) and to one image, showing U.S. sailors, even the words "porn actor", before his vandalism was detected and the account indef-blocked. --Túrelio (talk) 19:11, 2 December 2019 (UTC)

Choice of PoTD

There are discussions ongoing at Commons talk:Picture of the day as to how the PoTD is chosen and booked up. Please lend your opinion to the discussions. --Colin (talk) 13:31, 3 December 2019 (UTC)

FoP of New Zealand artwork: sculpture or graphic work?

 
Snowbound Cloak, Philippa Blair (1993): protected under FoP?

I've just started as a Wikipedian in Residence at Lincoln University, and began by taking photographs of its art collection that met the criteria:

  1. permanently installed
  2. in a public area
  3. 3D sculptures

I've had a complaint that the Philippa Blair work (pictured), permanently installed in a public area of the university library, is a painting, not a sculpture – so a copyright violation. It's a painted canvas model or evocation of a traditional Māori cloak. In my reading, NZ FoP applies to "sculptures" but not to "graphic works", which are defined (in the COM:FOP UK wording) as "any painting, drawing, diagram, map, chart or plan, any engraving, etching, lithograph, woodcut or similar work". The question is whether this is a "sculpture" or a "graphic work", and the distinction seems to hinge on whether it is 2D or 3D. I'd argue the latter, but if the consensus is it's a painting I'm happy to flag it for deletion. What do people think? —Giantflightlessbirds (talk) 03:59, 2 December 2019 (UTC)

@Giantflightlessbirds: Difficult to tell from the front but the shadows tell me it's 3D. The test I usually apply is "Does it have depth?". See, e.g File:Liverpool FC crest on Walton Breck Road.jpg which looks 2D but viewed from the side: File:Liverpool FC crest on Walton Breck Road - side view.jpg it clearly has depth. I wouldn't delete your image as non-compliant with FOP. Rodhullandemu (talk) 12:27, 2 December 2019 (UTC)
Yes, it definitely has depth; the canvas is folded in and back to evoke a cloak wrapped around an imaginary person. You can see a similar work by the same artist here. Note that she calls the works her "cloak paintings", which doesn't help us decide what category they belong in. —Giantflightlessbirds (talk) 13:01, 2 December 2019 (UTC)
@Giantflightlessbirds: Can the canvas be unwrapped? Actually, if I roll the canvas of a painting, it will be a cylinder (a tube), but that action will not transform the painting in a sculpture. On the other side, if the wrapping is part of the artwork, so that the canvas 3D shape is fixed (by using of special painting layers, for instance), we can consider it a sculpture. In other words, if flattening it ruins the work, it's a sculpture :) Ruthven (msg) 14:58, 2 December 2019 (UTC)
The canvas is folded and hung by eyelets to create a particular shape, because that's the whole point of the artwork – for it to look like a cloak. If it were unfolded, you'd be destroying the artwork, like unfolding a piece of origami. —Giantflightlessbirds (talk) 19:53, 2 December 2019 (UTC)
I think clothing isn't generally copyrightable? Although a design printed on it may be. --ghouston (talk) 00:37, 3 December 2019 (UTC)
It's not clothing; it can't be worn. Like I said, it's an artwork by a painter in the Lincoln University Art Collection. —Giantflightlessbirds (talk) 10:10, 3 December 2019 (UTC)
@Giantflightlessbirds: The artwork clearly has both 3D (sculptural) and 2D (graphical) elements. I imagine that copyright would still cover the 2D elements since they are "separable", i.e. you could easily reproduce the graphical elements on their own as purely 2D works. Kaldari (talk) 03:33, 4 December 2019 (UTC)
Hmm. I'm not sure the paint on the surface really can exist as an entirely separate artwork, as the "separability" argument implies. It sound like you're saying is the colour of a sculpture is copyrighted, but the shape is not! —Giantflightlessbirds (talk) 03:48, 4 December 2019 (UTC)

Macedonia / North Macedonia categories

I just moved {{Macedonia photographs taken on navbox}} to {{North Macedonia photographs taken on navbox}} because I have seen that category:Images of Macedonia was moved to category:Images of North Macedonia, but apparently not everything has been moved, and we have a horrible mess here. Does anybody know the current state of affairs? Have there been any discussions? What is the best way forward towards the fully aligned category tree? (This is not supposed to be a political question, I do not particularly care about the name itself, but we need to be consistent).--Ymblanter (talk) 22:03, 3 December 2019 (UTC)

But older photographs are taken in Macedonia and not in North Macedonia? I think we need both. --GPSLeo (talk) 15:01, 4 December 2019 (UTC)
Seems to me they should be moved, just like we have Category:1888 in Washington (state) even though at that time Washington was a territory, not a state. - Jmabel ! talk 17:41, 4 December 2019 (UTC)
Looks like that a common practice is to use the actual situation for the category name, see also Category:Russia by year and Category:Germany by year. Rudolphous (talk) 18:10, 4 December 2019 (UTC)
@Rudolphous: by "actual" do you mean "present-day"? ("actual" means that in a lot of languages, but not in English). - Jmabel ! talk 20:52, 4 December 2019 (UTC)
Yes, present-day. Rudolphous (talk) 21:45, 4 December 2019 (UTC)
(Edit conflict) That is a sensible solution most of the time. There is however a problem when people use the name of the category as sensibly interpreted and the category is then moved to something that does not correspond to that meaning. One should not make images of Greece Macedonia to be categorized as being from North Macedonia. If the category was well described from the beginning we can blame those using it, but I have seen examples where an category without description had an ambiguous name changed to a non-ambiguous without seemingly anybody checking what the images depicted (and the other way around) – and you seldom click on a category to check its description/categories unless you know it might be the wrong one. --LPfi (talk) 20:55, 4 December 2019 (UTC)

Insect list

Need a comprehensive insect list for submission of 2,000 photos:

Extended content

Category: 

                   Insects - Insecta

Alderflies, Dobsonflies, and Fishflies - Megaloptera


Alderflies – Sialidae

Dobsonflies & Fishflies - Corydalidae


Antlions, Owlflies, Lacewings, Mantidflies and Allies - Neuroptera


Antlions – Myrmeleontidae

Owlflies – Ascalaphidae

Lacewings & Mantidflies & Allies - Hemerobiiformia

Ants, Bees, Wasps and Sawflies – Hymenoptera


Ants – Formicoidea

Bees – Anthophila or Apoidea

Wasps – Sphecidae

Sawflies - Symphyta

Barklice, Booklice, and Parasitic Lice - Psocodea


Beetles & Weevils - Coleoptera


Bristletails - Microcoryphia


Butterflies and Moths – Lepidoptera

Butterflies – Papilionidae

Moths – Lepidoptera (Moths)


Caddisflies - Trichoptera


Cockroaches and Termites - Blattodea


Dragonflies and Damselflies -Odonata

Dragonflies – Anisoptera

Damselflies - Zygoptera

Earwigs - Dermaptera

Fleas - Siphonaptera

Flies - Diptera

Grasshoppers, Crickets, Katydids - Orthoptera


Grasshoppers – Caelifera

Crickets – Gryllidae

Katydids - Tettigoniidae


Mantids - Mantodea

Mayflies - Ephemeroptera

Primitive Winged Insects - Protorthoptera

Rock Crawlers - Notoptera

Scorpionflies, Hangingflies and Allies - Mecoptera

Silverfish - Zygentoma

Snakeflies - Raphidioptera

Stoneflies - Plecoptera

Thrips - Thysanoptera

True Bugs, Cicadas, Hoppers, Aphids and Allies - Hemiptera

Twisted-winged Insects - Strepsiptera

Walkingsticks - Phasmida

Webspinners - Embiidina

Zorapterans - Zoraptera

(Jacy Lucier (talk) 23:36, 3 December 2019 (UTC))

Hey Jacy Lucier I'm afraid it's not exactly clear what type of list you want. We have many thousands of categories related to species. What particular set of files are you planning to upload? GMGtalk 23:51, 3 December 2019 (UTC)

I don't have a clue how to reply to GMGtalk. Is there a "reply" button? GMG said: Hey Jacy Lucier I'm afraid it's not exactly clear what type of list you want. We have many thousands of categories related to species. What particular set of files are you planning to upload? GMGtalk 23:51, 3 December 2019 (UTC).

1. This list is all the 'categories' of insects in North America. 2. Yes, you have thousands of categories related to species, none in any kind of logical order. 3. The particular set of files are photographs from an 18 years study of insects in a wet hickory/oak forest, and represents over 2,000 species. Nearly all the 'categories' in my initial post are covered. (Jacy Lucier (talk) 00:48, 4 December 2019 (UTC))

Hmm...I'm not really sure who we could ping that would be an insect expert...Umm...@Jmabel: @Alexis Jazz: You all have any recommendations for who might be able to help? GMGtalk 01:10, 4 December 2019 (UTC)
You might look at who fills in info on my ignorant layperson's photos of "unidentified insect". The only one that leaps to mind is User:Notafly because the name pretty much indicates their interest in this. - Jmabel ! talk 01:54, 4 December 2019 (UTC)
@GreenMeansGo: wikispecies:Wikispecies:Village Pump? - Alexis Jazz ping plz 03:45, 4 December 2019 (UTC)
And maybe Charlesjsharp. - Alexis Jazz ping plz 03:48, 4 December 2019 (UTC)
I cannot understrand what Jacy Lucieris asking. Why do you need a list to upload images. 1. Identify the current scientific name, including subspecies if possible. 2. Make any corrections needed to the image (e.g. darkness) 3. upload entering correct binomial and geographical location. 4. Create new category if only genus category exists. 5. Add to Wikipedia if appropriate. 6. Submit to VI if you wish. Charles (talk) 09:21, 4 December 2019 (UTC)
@Jacy Lucier: To reply, click "edit" next to the section header and add your reply to the bottom. So you're new to wiki.. If you consistently put the correct information in the file name (species, location, everything Charlesjsharp says), we can take care of the categorizing. If you have any trouble with the UploadWizard you might want to try one of the Commons:Upload_tools#Standalone desktop applications. - Alexis Jazz ping plz 17:33, 4 December 2019 (UTC)

How do I request file mover privileges?

I intend to use this only for mistakes in my own uploads, to stop bothering others. Deisenbe (talk) 15:44, 5 December 2019 (UTC)

=> Commons:Requests_for_rights Gruss --Nightflyer (talk) 15:47, 5 December 2019 (UTC)

In compliance with the provisions of the US Digital Millennium Copyright Act (DMCA), and at the instruction of the Wikimedia Foundation's legal counsel, one or more files have been deleted from Commons. Please note that this is an official action of the WMF office which should not be undone. If you have valid grounds for a counter-claim under the DMCA, please contact me. The takedown can be read here.

Affected file(s):

To discuss this DMCA takedown, please go to COM:DMCA#BP logo. Thank you! Joe Sutherland (WMF) (talk) 20:13, 5 December 2019 (UTC)

For anyone who's curious, it was a version of the logo very similar to File:BP Helios logo.svg. The author, source, and license were all clearly bogus. It seems our upload patrolling failed in this case. Kaldari (talk) 00:33, 6 December 2019 (UTC)

Copyright question

Hi,

Can someone have a look at this picture please? I realize that copyright is handled differently in almost every country, but I am having a hard time imagining how the person depicted in the picture should have taken the picture themselves. The uploader goes by the name of the person in the picture and says "own work". How can that be? We are not supposed to assume that this is a selfie, are we? So wouldn't the photographer be the copyright holder? --217.239.10.88 11:30, 6 December 2019 (UTC)

@217.239.10.88: Maybe he had set up a camera with a timer. We can't ignore that we now have timers in cameras. We also have Remote Control Cameras and gesture controls. -- Eatcha (talk) 12:07, 6 December 2019 (UTC)
Like he set up a tripod right behind the second violins, set the timer, ran back up front and started to conduct, trying not to look out of breath? Or he had a little button to press with his foot for remote control? You can't be serious. --217.239.10.88 13:14, 6 December 2019 (UTC)
Not all those usernames are real. Sometimes, people hired by the artist create an account with artist's name. Ahmadtalk 13:20, 6 December 2019 (UTC)
In that case we would have a problem with the user name, wouldn't we? Wouldn't the user have to verify that he is the person he claims to be?
Secondly, what photographer in his right mind would give up his copyright and risk getting into some kind of legal muddle by using someone else's name? --217.239.10.88 13:44, 6 December 2019 (UTC)
Well, that's a part of the username policy, but as far as I'm aware, many people (both in here and Wikipedia) violate it this way, and, because verifying the real identity is a bit hard, we/I usually ignore dubious ones and focus only on obvious violations (e.g people who are really famous and well-known). The account holder can also be the artist himself as well, considering the evidence provided below.
About the second point, it can be a result of unfamiliarity. But, aside from that, this whole theory can be false, and they can be the artist himself. Ahmadtalk 16:38, 6 December 2019 (UTC)
  Comment Focal length of 200 mm tells me that for him to fill the frame, the camera is some distance away. The self-timer on that camera has a maximum setting of 20s. That makes me think that he would not have time to trigger it and have enough time to get back to his podium and appear to be in the middle of conducting. That doesn't rule out a remote control, of course, but by Occam's Razor, I don't believe he took it himself in any way. Rodhullandemu (talk) 13:27, 6 December 2019 (UTC)
Thanks for taking action. I agree with your assumption about probability. I would venture even a step further and assume that the most probable explanation is that this artist's PR manager copied & pasted a couple of photographs they thought would be useful here, thinking they were acting in the artist's interest (and therefore using his name as a user name). --217.239.10.88 13:49, 6 December 2019 (UTC)
Yes, this is likely an account created by the subject or on their behalf, and it is exceptionally common for new users to confuse being the subject of a photo with being the owner/creator of a photo. At any rate, even if the files are deleted, if they can come back at any point in the future and explain their copyright status satisfactorily, we can always restore them without too much trouble. GMGtalk 13:59, 6 December 2019 (UTC)

In case any more indications are needed that this user simply didn't understand copyright, here's another one (from the comment part of that picture): "L'image est en distribution libre. Elle a été déjà publiée en plusieurs sites internet."
My French is a bit rusty, but I take that to mean: "This picture has already been published in numerous spots on the internet. Therefore it must be in public domain." - Well, not quite. --217.239.10.88 14:09, 6 December 2019 (UTC)

Commons:Photo challenge October results

Harvesting: Entries • Votes • Scores
Rank 1 2 3
image      
Title Donne indiane raccolgono fieno - Uttarakhand India The work is done. Young smiling boy carrying rice during
the harvest in Si Phan Don, Laos
Author Garonzi Stefania Milseburg Basile Morin
Score 21 17 16

Congratulations to Garonzi Stefania, Milseburg and Basile Morin. -- Colin (talk) 18:00, 6 December 2019 (UTC)

Empty categories

I have a few questions about empty categories, i.e. categories that have been created but contain no files, either as a result of deletions or failure to upload images. 1: Is there a way to view a list or category of empty categories? 2: Does the presence of templates like {{Wikidata infobox}} affect or hinder the identification of empty categories? And 3: Is there consensus on the deletion vs retention of valid but empty categories? Commons:Deletion_policy#Categories primarily concerns misspelled categories unlikely to be used, not empty categories in general. I seem to recall that categories like Unidentified organisms and others using {{Unidentified header}} had language warning Admins to not delete even if empty, but that seems to no longer be present. Thanks, --Animalparty (talk) 22:36, 6 December 2019 (UTC)

@Animalparty: Special:WantedCategories and Special:UnusedCategories. What a coincidence, I just replied at User talk:JuTa#Category:Brummel (surname). - Alexis Jazz ping plz 22:40, 6 December 2019 (UTC)
And you were referring to {{Empty category}}. - Alexis Jazz ping plz 22:46, 6 December 2019 (UTC)
There is User:Achim55/Unused_categories as well. --JuTa 22:52, 6 December 2019 (UTC)
Empty categories used to be speedy deletable, which is why {{Empty category}} was created originally. Since the policy was changed, and empty categories are not speedy deletable just because they are empty anymore, the template is not as useful as it used to be. Sebari – aka Srittau (talk) 23:04, 6 December 2019 (UTC)

British library download

Hi. How can I download pages of this digitized manuscript in the highest resolution possible? The viewer the British Library employs is configured in a way that allows users only to download the section of the page that is displayed on the screen. I noticed the bigger the screen is that one uses, the higher the resolution of the downloaded picture becomes. I however would like to be able to download a full page as well as details of it in the maximum resolution that the Library is able to provide irrespective of the end device I use. Gun Powder Ma (talk) 19:25, 4 December 2019 (UTC)

First, have you checked in Category:British Library to see if it's there? From there, I'd see who has recently uploaded similar images and how they got them (a number seem to be taken from the British Library Flickr page). -- Ricky81682 (talk) 22:11, 4 December 2019 (UTC)
I have already downloaded successfully a couple of them. But afterwards I realized that I may not have done it with the highest possible resolution. That's why I am asking. Gun Powder Ma (talk) 08:38, 5 December 2019 (UTC)
@Gun Powder Ma: Try Dezoomify. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 11:03, 5 December 2019 (UTC)
The ophir dezoomify will automatically work on BL images, but multipage zoomed images may need you to look at how the series of pages have different sources which may not be readily apparent using the link in your browser bar as the sub-page/tiled images is changing, not the master page or container. See User:Fæ/dezoomify if you are unsure how to analyse how this works. --Fæ (talk) 11:06, 5 December 2019 (UTC)
@Fæ: The download through Ophir works fine for me but only for the very first page of the manuscript. For the others the URL is hidden. I tried your manual but I could not identify the URL, not in the least because once you refresh the page, it returns automatically to the very first one. Seems the BL makes a conscious effort to prevent the pics from being downloaded in maximum resolution. Gun Powder Ma (talk) 23:06, 6 December 2019 (UTC)
I figured it out eventually. The FAQ was a great help. Many thanks. Gun Powder Ma (talk) 13:14, 7 December 2019 (UTC)

Mirror image needs fixing - what template?

File:The Inn of the Parrot - Frank Brangwyn - ref Brangwyn-K07744.jpg is mirrored. I looked in Category:Image cleanup templates, but can't see a suitable template to flag this; is there one? Also, is there a bot to fix such issues? (The image also needs to be deleted until 2027, to complicate matters). Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 13:23, 7 December 2019 (UTC)

In fact the image above is correct - the artist worked the plate writing the lettering the correct way around, and then in the printing it reversed. The general question remains, however. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 16:24, 7 December 2019 (UTC)
I don't think there's a dedicated template for cleanup (although there is Category:Images to be flopped back). We may need one. I also think there should be a template for merely informing users that the image is mirrored (aka flopped) from the original, and that it should therefore be used with caution (but not necessarily targeted for "unflopping"). See Category:Flopped images. I envision a simple multi-lingual template that says basically This image has been flopped (mirrored) from its original orientation. It may be advisable to use the original rather than this if it misleads the viewer. The English Wikipedia Manual of Style for Images states: Images should not be changed in ways that materially mislead the viewer. For example, images showing artworks, faces, identifiable places or buildings, or text should not be reversed. I'd make it myself but I don't know how. --Animalparty (talk) 17:39, 7 December 2019 (UTC)
For a template with no parameters, just put it in "template" space at the name you want and, bingo!, you have a template. You can use {{Multilingual description}} within the template to deal with the multilingual aspect. - Jmabel ! talk 22:35, 7 December 2019 (UTC)

JFIF

I just tried to upload an image in JFIF (JPEG File Interchange Format) format, and it was not allowed. Why is that? Can we enable such uploads? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 10:59, 5 December 2019 (UTC)

This looks like a pretty technical question, depending on the nature of the file you want to upload. Presumably you uploaded as a .jpg extension and it failed to parse. I suggest raising on phabricator with a link to the specific image and the error message received.
As a non-dev, my understanding is that the system already sniffs out JFIF compliant metadata, the extent to which this might still fail, even though the file to be uploaded may comply with the JFIF standard, is something I have no yardstick for. --Fæ (talk) 11:20, 5 December 2019 (UTC)
typically this happens if the linux file command thinks the file is not a jpeg. This can happen if the file is malformed (especially the beginning part) but not malformed enough to prevent display. Sometimes this happens if the file could be multiple valid types, although that is pretty unusual. As fae said, open a ticket and upload the file to phab. Its impossible to say eithout seeing the file. Bawolff (talk) 05:01, 8 December 2019 (UTC)

Haeckel Hepaticae.jpg

 

This widely used image was recently renamed for inappropriate reasons. The original name "Haeckel Hepaticae.jpg" identified the author (Ernst Haeckel) of the scientific work in which the plate appears, and the name of the taxon being represented (Hepaticae). This is the name structure used for all of the other plates from this work. See Category:Kunstformen der Natur (1904).

The rename rationale given was "Criterion 2 (meaningless or ambiguous name) This image is a collection of liverworts, not one species"

It is true that this shows more than one species. But it is also true that Hepaticae is the name of a taxonomic class, like Insecta or Reptilia. An image named "Insecta" that showed many insect species would be fine, because "Insecta" is the name of the group that includes all insects. An image named "Reptilia" that showed many reptile species would be fine, because "Reptilia" is the name of the group that includes all reptiles. This is also true for this image. "Hepaticae" is one of the accepted taxonomic names for the group that includes all liverworts (hepatics), and "Hepaticae" is therefore a fine name.

Additional problems in the move result from the new name immediately after the move was "A mikxture of liverworts from Kunstformen der Natur (1904), plate 82.jpg" The original name was international (name of author, name of taxon), but the name name is in English, which makes the name less accessible. This name also contains a typo "mikxture" which should be spelled "mixture" in English. Further, the name "liverwort" is an ambiguous name, since the name "liverwort" can refer to members of the Hepaticae or of the obsolete genus Hepatica, which is a flowering plant (now Anemone).

Therefore the name name introduces the very problem that the move was supposedly going to correct.

I have temporarily renamed the file "Assortment of Hepaticae from Kunstformen der Natur (1904), plate 82.jpg" to alleviate the problem of the typo and of the ambiguous name, but I would ask the ill-advised move requested by @Cell Danwydd: and made by @VKras: from File:Haeckel Hepaticae.jpg to File:Assortment of Hepaticae from Kunstformen der Natur (1904), plate 82.jpg be reversed and the original name of the file restored. --EncycloPetey (talk) 17:02, 7 December 2019 (UTC)

  • EncycloPetey, thank you for your detailed account and argumentation. This renaming, and likely hundreds like it, should never have been requested, and should never have been performed. I am afraid that the most recent changes to COM:FR made it close to meaningless and and that frivolous filerenaming is running rampant. -- Tuválkin ✉ ✇ 17:21, 7 December 2019 (UTC)
  • Which changes do you mean? I can only see the stuff about suppressing redirects. The problems seem to mostly come from criterion 2) To change from a meaningless or ambiguous name to a name that describes what the image particularly displays. Perhaps "ambiguous name" should be removed or re-expressed somehow, since practically any name is apparently considered ambiguous by some. --ghouston (talk) 02:45, 8 December 2019 (UTC)

publicdomainvectors

Hello.

OpenClipart is down. There is an other site : https://publicdomainvectors.org/

A bot may upload all cliparts from this site to WikiCommons.

--ComputerHotline (talk) 09:37, 8 December 2019 (UTC)

Question or issue about the use of the "Author" field

Background

Recently I read some of the information at Commons:For_Wikipedians ... including, for example, the part where it says

Bear in mind that if on Commons one makes 500 bad edits in obscure file description pages, nobody will rush to revert them – here it is not like in Wikipedia where almost all significant pages are monitored.

under the "Don't be bold:" bullet, in the section

"Commons:For_Wikipedians#Cultural_differences".

OLD question or issue ... from more than 3 years ago

The comments in the << incorrectness_of_the_name_of_the_field_[now]_labeled_as_"Author" >> sub-section of the section "File_talk:Einstein_Szilard_p1.jpg#suggestion_for_possible_improvement" of a certain "Talk:" page (File_talk:Einstein_Szilard_p1.jpg) are perhaps a good *** EXAMPLE *** of an edit on Commons not getting very much attention.

Digression:
I tried (today) to create (here) a hyperlink to point directly to that sub-section, but I must have made some mistake in the wikitext, or in the wikilink, or something, because ...it did not work.
I used an attempt like this: << [[File_talk:Einstein_Szilard_p1.jpg#incorrectness_of_the_name_of_the_field_[now]_labeled_as_"Author"]] >> and ... as you can see, ... it did not work. It is almost as if the pair of double "square brackets" before and after File_talk:Einstein_Szilard_p1.jpg#incorrectness_of_the_name_of_the_field_[now]_labeled_as_"Author"
were being ignored. Maybe I failed to make some "percent-sign subsitutions" -- such as %22 for the "double quote" mark character -- ["] -- and so on. (OR ... something like that.)

The comments there -- (about the field [now] labeled as "Author") -- have been languishing for over 3 years ... and they have probably gotten little "if any" attention.

Please forgive me for inquiring here, if [it turns out that] this is the wrong place to find out how to suggest that someone should "consider" the ideas there, and/or respond.

Thanks for listening. --Mike Schwartz (talk) 20:33, 5 December 2019 (UTC)

@Jmabel: YES. My comments from "20 May 2016" can be seen right [[ here ]]. (That link may also be shown above, but ... if this is any easier, for you, then ...go for it. Just "FYI").
By the way ("BTW"), thank you for that prompt response. And, since the paragraph with a heading saying << "Digression:" >> was indented ... well, the intention there, was: that you could then easily SKIP that part, if you were not interested in something that is (mostly) unrelated to the main topic of (the "incorrectness of the name of the field [...]" sub-section of) my comments from "20 May 2016".
I hope this helps. --Mike Schwartz (talk) 06:18, 6 December 2019 (UTC)
  • That is also a screen-and-a-half of text. Would you please clearly state a specific concern about a specific file? Perhaps someone here has time to wade through that, but if you came to the Village pump to get something done, it helps to be succinct and to the point. - Jmabel ! talk 06:28, 6 December 2019 (UTC)

@Jmabel: If I understand correctly, Mike Schwartz asked on the image's talk page a) if line breaks can be added to the named & address of the museum that supplied the image (I have just done so) b) if it's appropriate for the source museum to be listed as "author" for a letter written by someone else. I expect that he's implicitly asking if Commons:Don't be bold is an appropriate suggestion, given that his proposal for these very minor changes on an image talk page several years ago were left unanswered. Thoughts on the issue of the "author" field would be welcome. - Themightyquill (talk) 10:48, 6 December 2019 (UTC)

@Mike Schwartz: The only user usually notified of comments on a file talk page is the uploader. In this case, Trassiorf seems to have stopped contributing before you made your comment, so in all likelihood, no one saw your question until now. Asking at the village pump was a better idea, though as Jmabel as suggested, brevity/clarity will help you get an answer sooner. - Themightyquill (talk) 10:48, 6 December 2019 (UTC)
I suppose Einstein is the proper author, and the library would ideally be mentioned in the source field, not the author field. But I don't think it is a big deal. - Jmabel ! talk 19:17, 6 December 2019 (UTC)
Thanks for listening, and thanks for responding.
I had a look at the DIFF listing for the only change to this "commons" file within the past 5 years or so.
The changes shown there, basically boil down to ... inserting "line breaks" between (the values of) the following sub-fields:
  • "Name" : Franklin D. Roosevelt Presidential Library & Museum
  • "Address" : 4079 Albany Post Road
  • "City/St/ZIP-code" : Hyde Park, NY 12538
of a certain field in the metadata for [one page of] a certain document. I am satisfied with those changes, and I think that they were a good idea.
Now, as far as ... whether the field that contains those three sub-fields, should be called "Author", or whether it should be called something else ... such as, perhaps "Owner", I am not insisting on my own opinion being given preference over the usual /slash appropriate "consensus" process within the way Wikimedia [Commons] works. (that is, "commons dot wikimedia dot org") *If* -- now or in the future -- one or more readers should happen to read what I wrote, (about what I think that field should be called) ... then maybe there is a chance that they will see fit to recommend (or "vote" for) a certain new "consensus".
But if that has not happened yet -- and moreover, even if it does not ever happen -- then the planet will continue rotating on its axis, and the internet will probably continue to become ever more interesting and more useful over time, and ... I can live with that. Then, even if becoming an "activist" to promote a certain suggestion is permitted on Wikimedia [Commons] (i.e., "commons dot wikimedia dot org") ... it might not be my choice for the best use of my time and talents. Not everyone will want to lobby for a certain idea, even if it is supposedly (or "allegedly") a good idea.
I might not be back here (on Wikimedia Commons) very often (compared to the frequency of my visits -- both to read and [sometimes] to edit -- on English Wikipedia). I am not "sure" that I will visit Wikimedia Commons as rarely in the future as I have in the past, but ... if I do, then ... carry on [mostly] without me.
Best wishes for success, and for being (oops, continuing to be) kind to each other, [here and elsewhere]. --Mike Schwartz (talk) 05:13, 9 December 2019 (UTC)

Borders

I was wondering why the following files show Somalia being split in two:

In particular this deserves conjecture when you consider the wikipedia pages for relevant provinces such as Cayn and Sanaag show that these regions aren't under Somaliland's control. Miketrhawrp865 (talk) 01:25, 9 December 2019 (UTC)

As in en:Somalia: "(...) Area controlled by Somalia shown in dark green; claimed but uncontrolled Somaliland⁠ (a self-declared but unrecognized state) shown in light green. n.b., zones of control are approximate at this time.". Somewhat like in en:Russia for crimea: "Location of internationally recognized territory of Russia (green) and the disputed Crimean Peninsula (light green)". Alexpl (talk) 08:03, 9 December 2019 (UTC)
My guess would be because Natural Earth showed Somalia being split in two when those maps were made (apparently 2011-2014). Those maps that cite their sources claim Natural Earth, and it seems unlikely that the people making the maps would have bothered changing borders in Somalia. --bjh21 (talk) 19:22, 9 December 2019 (UTC)

Polish history expert needed

There was an little edit war between two IP users 77.6.110.22 and 2A02:8108:1340:5E70:909A:AAE6:ACA5:F80E. The first created Category:Poznań during the Prussian annexation and added some files and categories the second one removed all from these category. I am not familiar with the topic and can not decide what is correct. Can someone help me here? Thanks. --GPSLeo (talk) 19:06, 9 December 2019 (UTC)

I am not an expert in this domain, but since its establishment in 10th century Poznań (German: Posen) vast majority of the time in its history has been a Polish city. When due to partitions Poland lost independence at the end of 18th century, Poznań for over 120 years belonged to (Kingdom of) Prussia. E.g. the article on German Wikipedia has a section about it: Posen#Preußische Zeit (1793–1918). So IMO the first IP is right and we can talk about "Prussian annexation". --jdx Re: 11:35, 10 December 2019 (UTC)

Special:SuggestedTags

Special:SuggestedTags, the page for accessing the computer-aided tagging tool, is now live for all auto-confirmed, logged-in users. There are no plans to make this tool available for anonymous or new users. Edits made using the tool are like any edit made here on Commons - they show up in recent changes and page histories, are tagged as being from the tool, and work with rollback/undo. Feedback about the tool is welcome on the tool's talk page. Keegan (WMF) (talk) 21:34, 11 December 2019 (UTC)

I should note that there is a known issue in the text display on the special page when viewing it while logged out. Apparently there is some strange parsing behavior that shows up in production Commons, but not on Test-Commons, BetaCommons, or local development instances. It's getting sorted out and patched. This is fixed. Keegan (WMF) (talk) 21:37, 11 December 2019 (UTC)

HEIC Files

Tracked in Phabricator
Task T211745

Hello Village Pump gatherers. I have attempted to upload photos and discovered that HEIC files are not accepted. Is this condition being addressed so that HEIC files may be uploaded? I am interested to hear from any who know. Most kind regards.Hu Nhu (talk) 23:07, 11 December 2019 (UTC)

@Hu Nhu: Commons:Village pump/Technical/Archive/2018/12#Adding HEIC format images to commons - Alexis Jazz ping plz 23:42, 11 December 2019 (UTC)

Upcoming change to search - using the search bar will always go to results

Tracked in Phabricator
Task T235263

As you may recall, several years ago the wikis got a new search engine. Search has overall greatly improved the quality of life since release, but unfortunately it was never optimized for some of the sites like Commons.

There is an upcoming change related to this. Currently, when you use the search bar at the top of the page, if there is an existing page on Commons for that word the user will be taken to that page instead of the search results for the word. For example, if I come to Commons to look for a picture of a dog, I'll put "dog" in the search box. Instead of getting the results from Special:Search/Dog, I get the page Dog. This was not intended behavior for Commons; going directly to the page is behavior intended for Wikipedias. The intended behavior for Commons is what Special:Search does, which is present a list of potential matching files in addition to links to the page Dog. To be clear, when searching after this change, you will still be presented with the link to the page Dog as your first option.

This change will not be alone, there will be more changes in the future to how search is served on Commons. The benefit of manually curated pages when search results are messy can be clear, but it leaves out a significant amount of media. By making some changes over time, cleaning up the search results page will be beneficial. Keegan (WMF) (talk) 16:49, 2 December 2019 (UTC)

AWESOME! - Alexis Jazz ping plz 16:56, 2 December 2019 (UTC)
I have been very annoyed by the original change and hope the problems could be alleviated by specifics in the new change.
The problem is that I cannot use the search box to get to a specific page that is not found on Commons. When I type "en:Dog" I get presented with all those lovely media, which I am not interested of for the moment – and there is no link to the page I asked for on the page I got. I know I could use the URL field of my browser, and I do use Monobook with a separate search button (but hitting return started to take me to the annoying search page).
Couldn't the search page logic recognize the sister project and namespace shorthands?
I do get annoyed also when I am trying to get at a page that exists on Commons. I did type in the name of a page I knew exists, thank you very much for pointing out that there is such a page instead of taking me there. Was it really that hard for "users" to make a distinction between "go" and "search"? – Or are we following the lead of companies that wanted us not to make that distinction?
--LPfi (talk) 20:45, 4 December 2019 (UTC)
There was a team at the Foundation that did some research into cross-wiki search a few years ago. The end results are that it's actually very hard to do considering database sizes as well as languages, as well as other large technical hurdles (ref). That's not to say it might not still happen in the future, but it was too much for the team at the time and was put on hold. Keegan (WMF) (talk) 18:21, 9 December 2019 (UTC)
Is there any tool to restore the original behaviour? This is really annoying... — Draceane talkcontrib. 20:45, 10 December 2019 (UTC)
I would also like to know if we can still use it as before. If I type in File:Foo.jpg or Category:Bar, I am very certainly trying to get to a specific page. At some point, I placed GoButton=true in my common.js. Why can't that still work? kennethaw88 • talk 05:50, 12 December 2019 (UTC)
@Keegan (WMF): if you enter "phab:" or "phab:T1234" in the search field, you will not be interwikied to phab and the list of search results has no link to phab. Also if you use the upload wizard, it will idle for an hour, than say "unknown error: "$1" " at com:Forum you will find a section upload wizzard with a number of people complaining about the same error and not creating phab tasks. Neither will I, Ido not have a link to phab. --C.Suthorn (talk) 12:28, 12 December 2019 (UTC)
To anyone who wants the original behaviour back - go to Preferences -> search tab -> check "Redirect to exact matches when searching". Sorry that we missed this in the original announcement CParle (WMF) (talk) 17:47, 12 December 2019 (UTC)
  • I dunno about anything else, but this should be disabled for project space. In no universe is someone typing COM:V2C or COM:VPP trying to do a search instead of using a short cut to get to Video2Commons or the Village Pump. GMGtalk 18:00, 12 December 2019 (UTC)

"No license since" question

 
"I'm happy that I'm public domain!"

I recently transferred 2 images from Flickr that are credibly in the public domain (17th-century manuscripts: 1, 2), yet that were tagged on Flickr with the problematic version 1.0 of the Creative Commons Public Domain Mark. Although I added more informative templates during the transfer, the resulting uploads had both a suitable {{PD-old-100-expired}} and {{No license since}}, targeting them for deletion: see [2] and [3]. While the {{No license since}} has since been removed by hand, which is feasible for small numbers of uploads, my question is: what would happen if no one removed the {{No license since}} within 7 days? What if I transferred 300 such images and neglected to remove {{No license since}} on each one? Would an admin delete the images, or would they notice the appropriate PD template is present? Is there a bot or a tool that can detect when both {{No license since}} and valid license templates are present, and automatically remove the former, saving time for uploaders and admins? --Animalparty (talk) 20:23, 11 December 2019 (UTC)

  • Probably depends how much of a hurry the admin was in, and whether they were looking carefully. But if, as the uploader, you know the files in question are correctly tagged here (license tag or appropriate PD tag), it's pretty easy to mass-remove the incorrect "no license since" notifications with VisualFileChange. - Jmabel ! talk 01:21, 12 December 2019 (UTC)

If you wish you may add trusted websites or YouTube/Vimeo channel IDs to

User:YouTubeReviewBot/Trusted -- Eatcha (talk) 05:08, 12 December 2019 (UTC)

  Info they will be reviewed by others, do not add crap. You are also requested to police others entries. -- Eatcha (talk) 05:11, 12 December 2019 (UTC)

Trying to find "Shyarahalli"

User Kiran K H has a series of images with the word "Shyarahalli" in the file names. I tried to find more info about that in the English Wikipedia to put the right category with these files. A search gives several hits as for example "Gummanahalli Shivanahalli Shivapura Shivara Shivhalli Shravanahalli Shyadanahalli Shyarahalli Siddapura Sindaghatta Singanahalli Singapura Sirapatna Sirapura Solaba". On the page of Gummanahalli I could not find anything about "Shyarahalli". Any explanation for this? Thanks, Wouter (talk) 16:34, 12 December 2019 (UTC)

Large tiff files do not pass file verification

Tracked in Phabricator
Task T240455

Hi! I've been uploading some tiff files for a GLAM and some of them keep giving me "This file did not pass file verification" errors, both in the Upload wizard and when uploading via API (pattypan). However, this consistently happens only with files that are at least 200MB in size. All the smaller files in the particular batch of scans have been uploaded successfully, and they have the same kind of metadata etc. as the large files. Has anyone dealt with such a problem? Here's an example of a file that does not pass verification (320 MB). Cheers, Alicia Fagerving (WMSE) (talk) 07:41, 10 December 2019 (UTC)

Based on the comment in Phabricator, you could test out whether the redundant Alpha channel is the problem by removing it in an image editor. As these were originally processed in Adobe Photoshop, someone might be able to try it in Photoshop for the example. Even if this is not fixed at the WMF server verification end, it would be possible to create batch download the large files locally, strip the Alpha channel data without losing any other data, then upload each file to the WMF server. --Fæ (talk) 12:28, 13 December 2019 (UTC)
Just to clarify what I meant on the bug - image magick seems to be hanging on determining if the file has an alpha channel. The file itself doesn't appear to actually have an alpha channel (If I'm reading the output of the tool I'm using right, it is a 16-bit greyscale image, no alpha), it gets rejected because mediawiki can't figure out whether or not it does have an alpha channel. I have no idea why its hanging on this file and not others. Sure the file is big, but there are much larger tiffs on commons. Bawolff (talk) 18:32, 13 December 2019 (UTC)

Font awesome icons

Is it OK to add https://fontawesome.com/icons/ice-cream?style=solid to commons? I am unable to track down the licence, but I am also unable to do this with say https://commons.wikimedia.org/wiki/File:Font_Awesome_5_solid_chess.svg

Where Font awesome hides its info about open licencing of its free icon set? Mateusz Konieczny (talk) 14:54, 13 December 2019 (UTC)

And now I found https://fontawesome.com/license/free (and on downloading the file) Mateusz Konieczny (talk) 14:56, 13 December 2019 (UTC)
File:Ice-cream-solid.svg <- uploaded, hopefully everything is OK Mateusz Konieczny (talk) 15:01, 13 December 2019 (UTC)

Unknown error: "$1".

Tracked in Phabricator
Task T240698

Anybody else getting this error when trying to upload? GMGtalk 16:16, 13 December 2019 (UTC)

@GreenMeansGo: A known long term bug. See phab:T208186. Masum Reza📞 16:25, 13 December 2019 (UTC)
It concerns me that the Foundation is busy tinkering with New Files Feed and tinkering with the search function when a major core feature of the project has apparently been broken for the past 14 months. GMGtalk 17:04, 13 December 2019 (UTC)
This bug came up elsewhere this week, I think someone will take a look at this Monday. Non-developer observation is that when a ticket like that has sat around that for that long, there's a good chance someone took a look and found an infrastructure issue causing the bug that is either very challenging, or in many cases cannot be fixed. However, if that's the case, the bug can certainly fail better than Unknown error: "$1". I think we all agree there. Hopefully, though, the bug can actually be fixed as the best case. Worst case, a much better handling of the error and error message. Keegan (WMF) (talk) 17:53, 13 December 2019 (UTC)
Given the generic-ness of the error message, its entirely possible its a totally separate issue from the old bug (Or it could be the same, who knows. It doesn't look like there has been much investigation into the root cause of what actually went wrong). Bawolff (talk) 18:39, 13 December 2019 (UTC)
btw, I'm not the one looking into this, and I don't know for sure what would be useful, but if people want to report this, including the timestamp of when this error happened, what the destination filename was, what the filekey was (e.g. from Special:UploadStash) and (ideally, although this requires more technical knowledge) what the json api response that was sent to the browser to trigger this error was, would probably be helpful. Not sure if that would actually help the devs looking into this, but it certainly wouldn't hurt. Bawolff (talk) 19:07, 13 December 2019 (UTC)
Hmm...yes,I see. GMGtalk 19:23, 13 December 2019 (UTC)
I've bumped this on Phabricator by opening a new task. This is not the only problem with the Upload Wizard. Rodhullandemu (talk) 19:29, 13 December 2019 (UTC)
The cause may be found, it should get fixed. Keegan (WMF) (talk) 21:54, 13 December 2019 (UTC)
I have reported errors of the upload wizard more than once at phab, sometimes with file keys sometimes with the names of uploaded files, but basically got the anwser "provide a way to recreate". That does not work with a sporadic error. This has repeatledly cost me much time over the months. It does now. However more is at fault with the wizard: If you use the wizard twice (or more than twice) without reloading the wizard's html page, you will always get the "you are already uploading <first file of the new upload>". If you upload more than 150 (500) files in the same session but different runs it will not do it, because you "excede" the limit of 150 (500). the wizard has memory leaks, the tabs of the wizard crashes sooner or later and with firefox the whole browser crashes. Still the wizard gets more and more functionality (structured data) without fixing the existing problems. It would probably reduce the problems if there was an option, not to show tumbs during upload or to minimize use of javasript by an option to turn of autocompletion of categories or such luxory. --C.Suthorn (talk) 22:22, 13 December 2019 (UTC)
To be clear, the cause of the issue preventing the "retry upload" button from working has been identified. The reason why uploads are failing in the first place still remains a mystery. Bawolff (talk)

UploadWizard

UploadWizard does not work at all or needs a lot of time. What is the alternative ? --GFreihalter (talk) 19:50, 13 December 2019 (UTC)

@GFreihalter: Please see above item, but meanwhile Special:Upload is still working. Rodhullandemu (talk) 20:15, 13 December 2019 (UTC)
Commonist or other such tools will probably not be affected. --C.Suthorn (talk) 22:24, 13 December 2019 (UTC)

Please restore deleted legal images of Category:A. A. van Achterberg Collection

Dear @~riley Riley (or someone else?),

You deleted a lot of files which were legally on Commons. The author and donor of these files had provided the necessary permission for the license CC-BY-SA-4.0 and sent it to OTRS-NL weeks ago - please put those images back, it was a lot of work uploading them: 80 MB .tif files. OTRS permissions-nl asked me previously, NOT to put any license on donated uploaded files: they wanted to do that themselves, but they had not done this yet. Now i have tried to put the license on the remaining files anyway. So please restore those files you deleted, thank you! Hansmuller (talk) 16:39, 2 December 2019 (UTC)

@Hansmuller: I'll repeat what I always say when it comes to file donations and OTRS (probably said it to you before): Get OTRS sorted out before you start uploading. That will save everyone a lot of time and possible frustrations. I'm sure Ciell or one of the other Dutch OTRS volunteers can help you with that. Multichill (talk) 11:14, 4 December 2019 (UTC)
@Multichill: @Ciell @Ellywa Permission was given and sent to OTRS-nl on 10 October 2019, BEFORE my uploads for Achterberg started. Of course i don't upload before permission is granted to me and OTRS, what do you think ;-). I have always followed instructions for OTRS (for instance NOT putting CC-BY-SA-4.0 on the images), which unfortunately led to these deletions. Cheers, Hansmuller (talk) 04:27, 7 December 2019 (UTC)
  Agree Thank you very much Multichill, and I totally agree. OTRS, same as Commons, is managed by volunteers. Best is to first contact us, and get things sorted. Then we can tell you what the next steps will be. This might be different for different collections. Ciell (talk) 19:01, 5 December 2019 (UTC)
@Hansmuller: You cc-ed OTRS in a request to a photographer, who never confirmed the permission to us. Please try again and leave a comment on the Commons:OTRS/Noticeboard if you have any other questions. Ciell (talk) 19:07, 5 December 2019 (UTC)
@Ciell @Ellywa : But this photographer A.A. van Achterberg did confirm the permission to you, you already found the mail of A.A. van Achterberg to permissions-nl@wikimedia.org with the date "Do, 10 oktober, 2019 6:39 pm" , CC to me, here at ~riley 's . It is there in the "Extended content" {{cot}} put there by our famous superuploader Fae ! It should be in the Dutch OTRS archive, but without a ticket number because there wasn't yet any. What more do you need? Please don't keep me hostage any longer and restore those excellent Achterberg images. Thanks a lot, groetjes, Hansmuller (talk) 15:06, 6 December 2019 (UTC)
  •   Not done There are now conversations going on at four different locations, please stop cross-posting this. Ellywa is managing this ticket and will request undeletion once permission is verified. ~riley (talk) 19:55, 6 December 2019 (UTC)
    • @~riley I'm sorry when all of this is irritating, i agree. Please restore these images which were deleted caused by a misunderstanding as you mentioned at User_talk:~riley. (Ciell had asked me to cross-post on the OTRS/Noticeboard, like your text on your talkpage.) These images could be restored as "OTRS pending" which they were (although the donor sent permission in October 2019, as you saw too. I have contacted Dutch OTRS.). The point is logical. Some of the deleted images were included in for instance the GLAM institutional page w:nl:Wikipedia:GLAM/Afrika-Studiecentrum#van_Achterbergcollectie_Marokko,_Mauretanië,_Tunesië_en_Kameroen,_1997. I need them for another presentation for museums and cultural institutions in the Netherlands, through the Dutch chapter of Wikimedia, WMNL.
      Undeletion of this part of the collection is unconnected with the final permission which can remain pending, like is stated on the other images in the Category:A. A. van Achterberg Collection, for which permission is indeed pending too.
      The present situation turns out to be aggrieving to me (through no fault of me or of the donor).
      Please be logical and have a heart, restore and keep them OTRS-pending. Thank you a lot, Hansmuller (talk) 03:24, 8 December 2019 (UTC)
        • No, I did not ask you to cross-post: Multichill suggested you should get things sorted before you contact OTRS, I agreed and said you should get permission first, then move things to the our noticeboard if you have any extra questions. Ciell (talk) 21:24, 9 December 2019 (UTC)
      • Once we delete images where an OTRS investigation is ongoing, we do not ever normally restore them as OTRS pending. When the matter is resolved, if it is decided to keep them, they will be restored.
      • If you need them for a presentation, you presumably have copies on your own computer. If you specifically need them on the Web for your presentation, you can upload them to Flickr or some other site that is less concerned with copyright, and if needed you can take 10 seconds to explain the situation and why they are not yet on Commons.
      • I'm sorry this isn't going entirely smoothly, but you just got turned down by an administrator who, unlike me, is also an OTRS member and it is extremely unlikely that someone else will overrule them. - Jmabel ! talk 22:35, 8 December 2019 (UTC)
@Jmabel (Afterwards) No, thanks for the suggestion, to be precise, i don't have these files on my computer. Hansmuller (talk) 13:41, 9 December 2019 (UTC)
  •   Info Ellywa has decided to not invest more time in this ticket because Hansmuller is en:WP:NOTGETTINGIT, and while Ellywa has offered for me to take it over, I have decided it is best for this thread to continue in the native language. It will be taken over by a different OTRS member instead. Ellywa's original concerns remain. The permission sent by the author was for "photos from Africa", this is not specific enough and does not meet our requirements to host hundreds of these photos. These files were deleted for missing permission, not missing licenses and Wikimedia Commons' policy is that a file cannot have {{OTRS pending}} for more than 30 days - this is why I am not able to undelete these files. ~riley (talk) 23:29, 8 December 2019 (UTC)
Well OK(?) then, it appears i have to wait how this pans out. Sorry for the hassle. Ellywa was not specific which form an extended permission by the donor for hunderds of scans should take, so it was impossible to comply to whatever she might mean. (I suggested a checksum for each image?, but she did not go into details. Naturalis Leiden allowed me to upload say 6000 images a day, total say 275.000 images, please refer to Category:Media_donated_by_Naturalis_Biodiversity_Center, so a required permission for each image separately would have been interesting ;-)). Ellywa's recent unspecified request came nearly 2 months after the donor gave her permission CC-BY-SA-4.0 . Of couse i am willing to discuss anything and to do anything to further Wikimedia. At the same time we probably don't want an unneccesary bureaucratic hell and i also have to protect the donor from hassle. Thank you, let this not spoil your good day, Hansmuller (talk) 09:43, 9 December 2019 (UTC)
Hansmuller wrote: Ellywa was not specific which form an extended permission by the donor for hunderds of scans should take. This is completely besides reality. I tried to explain, I even made a special page on NL Wikipedia to help Hansmuller, how to obtain permission for uploading large numbers of images, nl:Wikipedia:OTRS/Groot_aantal_afbeeldingen. But to no avail. This is absolutely my last comment on this, I spent several hours on this. Asking the copyright holder for correct permission is a matter of no more then 10 minutes for Hansmuller, using the helpful list Riley made. Full stop. Elly (talk) 11:17, 9 December 2019 (UTC)
  • I'm sorry for this unpleasant discussion, a Dutch quarrel?
    Now the donor cannot see which images are deleted, that list means nothing to her. How can i ask her permission for what? And now more images have been deleted, so the now old list is not complete. And what about the other images, which the donor approved months ago, which are now threatened by Ellywa?
    She still has not specified at all on my explicit request how the approved images have to be identified according to her new personal rules?, she did not reject or allow an, e.g., checksum, identification. The donor has given an overall permission for all the slides she delivered to the Afrika-Studiecentrum Leiden (Center for African Studies), and most likely does not want to be bothered with still unclear new legal subtleties (?, what are they? why?) that are not easy to implement (how?) much less to explain them to a practical Africanist like she is?
    Unfortunately Ellywa is not aware of appropriate copyright laws and conventions, such as the Berne convention. Her interesting page nl:Wikipedia:OTRS/Groot_aantal_afbeeldingen in Dutch is tentative at best, and should be made practical before it could become authoritive. Nobody can be forced to do the impossible, isn't it?
  • All nitpicking aside, the point is that i am a Wikipedian in Residence at the Afrika-Studiecentrum, and have to deliver. Our project is damaged by these unneccessary troubles about copyright (?), which was settled by the donor on October 10, 2019, when no further demands were made. (I appreciate the valuable contributions Ellywa made in the past, but unfortunately cannot support her actions here which damage the Wikimedia Project). These seems to be bad days for the image of Wikimedia and its projects in The Netherlands, or do i exaggerate? (Now the images in both Category:A. A. van Achterberg Collection Achterberg 1 (nearly all) and Category:A. A. van Achterberg Collection Achterberg 2 (all) seem to have been deleted ;-))
  • This whole discussion seems out of place here, I apologize and hope the best for Wikimedia Commons. Although Ellywa in practice does not agree, our work here is "making available ... freely-licensed .. content .. to all, to be used by anyone, anywhere, for any purpose".
    I just want to go on fulfilling this mission of Wikimedia. Thank you, best wishes, Hansmuller (talk) 12:21, 9 December 2019 (UTC)

Can I be of any help? I was the original contact for the person who donated these photographs. She was perfectly happy with the Creative Commons licence, and we spoke at length about the way the photographs would be uploaded to Commons. If I can assist or communicate about this donation in any way, please let me know. I can be contacted via Talk page or e-mail, if need be. Vysotsky (talk) 13:40, 9 December 2019 (UTC)

Someone else who had recent experience with large uploads is nl:Gebruiker:85jesse who did this for "Beeld & Geluid". Maybe he has some advice. --VanBuren (talk) 20:46, 9 December 2019 (UTC)
@VanBuren Thanks VanBuren , however i did 280.000 uploads hassle-free , so experience is no problem, but OTRS-nl is. Hansmuller (talk) 12:57, 14 December 2019 (UTC)
That is a very kind suggestion, but please let the OTRS-agent (effeietsanders) handle it. Ciell (talk) 21:24, 9 December 2019 (UTC)
@Hansmuller: attacking Elly is not going to help your case at all. You made a mess, your damaging your own project, don't try to put the blame on someone else especially not on on the person who tried to help you.
So drop it and focus your energy on securing a proper permission. Don't worry about any already deleted files, any admin can easily retrieve them at Special:DeletedContributions/Hansmuller. Multichill (talk) 21:58, 10 December 2019 (UTC)
@Multichill What do you mean : "You made a mess"? I really never made a mess, as you can know. Ellywa just tries to block legal uploads and delete legal files, this is not what one calls help, isn't it? Hansmuller (talk) 12:54, 14 December 2019 (UTC)
@Multichill @Ciell There was a proper permission from the donor (according to previous demands from OTS-nl) since October 10... If OTRS (Ellywa?) does not act in 7 weeks and Ellywa in her ignorance then bullies me with for instance new illegal strange impractical new demands (Ellywa does not want to explain? File lists with no meaning? Renegociate permission from donor? OTRS permission viewed as a personal favor? Prohibition to upload?), a mess will ensue and we (I) lose time and energy... Please allow only sensible people at OTRS-nl...I previously uploaded about 280.000 files hassle-free, so ... Hansmuller (talk) 12:39, 14 December 2019 (UTC)
@Multichill @Ciell Because of this foolish mess with deleted legal files i was not able to correct metadata according to the wish of the donor...Hansmuller (talk) 12:45, 14 December 2019 (UTC)

Color mixup

This user seems to have uploaded a bunch of road signs with questionable coloring. I can't entirely rule out the possibility that they exist somewhere, but they are at least in need of an explanation, or better yet, of a source.

Another user already asked about one of them on that user's talk page in September but never got a reply. I posted my question there too but am not too optimistic about getting a reply.

How to proceed? --91.34.39.115 16:59, 8 December 2019 (UTC)

Assume a case of "Red–green color blindness" with the original creator an correct or delete the files in question. Alexpl (talk) 18:52, 8 December 2019 (UTC)
Considering that he named the file "Germany Prohibition for vehicles of all kinds Green & White" I find it hard to assume color blindness. :-)
I just posted the question on the German Wikipedia road sign talk page. Maybe someone from there will come by and let us know that these color schemes do exist somewhere. --87.150.13.17 09:58, 9 December 2019 (UTC)

To be honest, I am starting to wonder if this is a hoax. Have a look at this upload by the same user:
https://commons.wikimedia.org/wiki/File:Unofficial_Netherlands_-_Parent_dragging_a_child_Sign.png
--87.150.13.17 10:18, 9 December 2019 (UTC)

Seems to be from this exhibition with several joke road signs and should be denoted as such. --87.150.13.17 10:28, 9 December 2019 (UTC)

O.k. I decided not to nominate the files for deletion but to correct the categories and make it clear that these are fictional or private signs that are not in official use and have no official significance.
It would be nice though if someone who knows how could correct the file names. Both "Do not pass sign" and "Firefighter Accessibility Sign" are blatant nonsense. Notwithstanding the fact that none of these signs has any legal meaning at all, "Durchfahrt verboten" means "No entry" or "No thoroughfare", and the "firefighter accessibility" sign uses the diagram of the official "No stopping any time" sign, so I would suggest renaming these "No entry" and "No stopping", resp., or something like that. Thanks. --87.150.13.17 23:58, 9 December 2019 (UTC)

Maybe we could add a category "Signs that nobody needs"... ;-) --217.239.13.171 16:59, 10 December 2019 (UTC)
Which can, in turn, go in a category "Categories that nobody needs". - Jmabel ! talk 18:00, 10 December 2019 (UTC)
  • Or rather deletion request discussions that should be speedily closed with "keep" and vadal IPs that should be blocked: Commons is not an exclusive repository of official roadsigns, but a general repository of media files — which may sometimes include roadsigns that are unofficial or even items for satire and pranks. I would maybe sympathize with a drive to delete purely rootless fictional items such as (apparently) this one, but then I saw photogaphic evidence of real life usage and now I see this is one more clueless crusader. -- Tuválkin ✉ ✇ 19:07, 10 December 2019 (UTC)
What kind of strange turn is this taking? Where do you see a "deletion request discussion", or a "vadal IP"?
Here's a friendly request for advice on how to handle a certain situation. What's wrong with that? Are you suggesting that IPs should not post questions here but rather be preventively blocked for vandalism?
The question itself obviously is perfectly sensible and justified. It must be allowed to ask what the policy is on keeping such images, or if this is going to confuse users and possibly make people add wrong or misleading images in Wikipedia.
Not sure what you mean by "photographic evidence". Yeah, so someone has put up a sign like that in their front yard. What's that supposed to prove, except that this is not a "firefighter accessibility sign" (since it takes an extra sign to tell people that)? --217.239.13.171 00:50, 11 December 2019 (UTC)
  • If there’s no actual DR being filed and if the renaming and editing are done under a good understanding of what Commons is (and indeed, of what these files are), then I’m good with it all. (I still have huge qualms about IPs when it comes to anything other than once-off contributions, but that’s matter for another time.) -- Tuválkin ✉ ✇ 06:18, 14 December 2019 (UTC)

Am I missing something here? (Roman history related)

The information at File:Emporer Galba 68-69AD.jpg indicates that this is en:Galba or one of the many people named en:Lucius Calpurnius Piso. But the source file seems pretty confident that this is en:Marcus Licinius Crassus and is even used at the lead image for that article. Is there something I'm missing here? GMGtalk 18:03, 11 December 2019 (UTC)

It seems your question has been answered at Commons:Help_desk#Putting_an_upload_in_the_right_place. - Themightyquill (talk) 20:15, 13 December 2019 (UTC)
Updated the description with some sources. This was clearly described as "unknown" at the Louvre, and we should stick to that. Wikipedia is not a reliable source for ancient history... --Fæ (talk) 10:49, 14 December 2019 (UTC)

Former physical geographic features

Do we have a category for former physical geographic features (hills that have been leveled, lakes and bays that have been completely filled, etc.)? - Jmabel ! talk 03:06, 14 December 2019 (UTC)

Category:Former lakes. Ruslik (talk) 05:26, 14 December 2019 (UTC)
Thanks. I see that chains up to Category:Former locations. I guess I can use that, but it seems a hodgepodge: a former country, for example, is a very different matter than a former hill or a former lake. Weird mix of physical and political geography. - Jmabel ! talk 09:22, 14 December 2019 (UTC)

Text on postcards, etc...

Which template should be used for handwritten text on postcards like this one? --Hedwig in Washington (mail?) 05:49, 14 December 2019 (UTC)

Check out {{Inscription}}. --Animalparty (talk) 05:54, 14 December 2019 (UTC)
I know about that one, doesn't really fit IMHO. Is there anything better / easier? --Hedwig in Washington (mail?) 06:15, 14 December 2019 (UTC)

Adding an "alphabetical sort" on the top of the PD-Harris-Ewing category page

Question-

How can I (or another editor) add an "alphabetical sort" on the top of the PD-Harris-Ewing category page? There are over 60,000 photos in that category and it would help myself and other editors to find files of interest to categorize (it appears that most are not categorized).

Thank you, --Tibet Nation (talk) 02:23, 14 December 2019 (UTC)

I have added a {CategoryTOC} to Category:PD-Harris-Ewing, but how can it be helpful, there is no system in the names of the files? --C.Suthorn (talk) 05:02, 14 December 2019 (UTC)

Currently, the category is alphabetic. For those with LCCNs (all of them?) these could be used as category keys, if that is preferred. Ping me if that's desirable. --Fæ (talk) 21:58, 14 December 2019 (UTC)
Are LCCN IDs informative or completely arbitrary? Do they correlate with date? Do they correlate with subject, such that related pictures of the same event will have consecutive IDs? Would sorting by ID be an improvement? I think we should have pretty strong consensus before we change any category keys on 67,000 images. Alternatives to altering category keys include using PetScan to identify and sort images like this one that are only categorized in Harris & Ewing Collection, PD-Harris-Ewing, and associated Hidden categories, i.e. images in need of more refined categorization. --Animalparty (talk) 23:00, 14 December 2019 (UTC)
Yes, no, yes, no, yes. --Fæ (talk) 11:28, 15 December 2019 (UTC)

Huge backlog at Category:License review needed (video)

Maybe we need more License Reviewers to clear the backlog, if they are not reviewed, their source URL would expire and we will be left with no other option than deletion. Please nominate trusted users for LR rights, if you are a license reviewer/admin try to review 1 video per day. I deployed a bot to review YouTube and Vimeo files but that only saves files from those 2 platforms, other source like Twitter,Facebook, Instagram, blogs and twitch are just waiting for their link to expire and finally getting deleted. -- Eatcha (talk) 11:17, 14 December 2019 (UTC)

Isn't there a bot that automatically backs up all links on video files to the Internet Archive? Per "Commons:Archive external links#Video files"? --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 20:52, 14 December 2019 (UTC)
Unfortunately not, we don't have IABot on commons. -- Eatcha (talk) 03:08, 15 December 2019 (UTC)

May set up a script to do the equivalent of IABot on some of the videos. The format would be very simple, no fancy templates, no new parameters and avoiding a specific archive date so that readers will be presented with all of the archive versions if they wish to verify the file:

  • <source> [http://web.archive.org/web/*/<source> archive]
  • Example: diff

Counter thoughts welcome, as there is no special hurry. BTW, 2,080 files (1,216 from YouTube) in the backlog does not feel like "huge" to me. --Fæ (talk) 10:59, 15 December 2019 (UTC)

{{From YouTube}} already provides links, for example File:"Cadet Classification" U.S. Army Air Force Training Film, 1942-43.webm. - Alexis Jazz ping plz 11:08, 15 December 2019 (UTC)
Not my preference. Templates that obscure the links and up transclusion count make like more difficult for mass processing later on. In this case editors are encouraged to not use a "youtube.com" link, which is slightly crazy in my book as this means that intuitive searches like insource:youtube.com will fail to find these images! The links given in the "From YouTube" template have not been checked so give no indication that an archive has been created. The simple link suggested uses zero templates and applies a standard link format, if added by Faebot it would mean that there is something to look at on web.archive, not that there is an action for someone else to maybe at some time do something. Doing it this way is also "agnostic" as the precise same format would be used for any source website, like Vimeo.
Of the listed backlog, perhaps surprisingly, only 71 YouTube files include the true original link to the video. This is so discouraging, showing unnecessary and avoidable complexity that needs to be programmed around, I may nobid on taking this further.
TBH, it makes sense to me to get {{From YouTube}} deleted and replace it with the actual source and web.archive links if and only if the source has actually been archived. --Fæ (talk) 11:24, 15 December 2019 (UTC)

Malfunction

There is a malfunction related to {{Category redirect}} and I don't see where the bug is sitting. a) Cats like for example Category:01 are members of the cat they are pointing to (here Category:1 (number)) what of course not should be if they are empty, b) the content of Category:Non-empty category redirects has increased to 3000+ entries most of which are empty even though there is shown "2 C" or "4 C, 1 F" or the like. Purging and touching the cat pages doesn't fix anything (as did in similar former situations). Somewhere the page counting seems to be messed. --Achim (talk) 13:09, 14 December 2019 (UTC)

Thats likely a server cache problem. A null edit would fix it. JuTa 20:19, 14 December 2019 (UTC)
No, it isn't, touch = null edit. --Achim (talk) 13:28, 15 December 2019 (UTC)
Not all category redirects are affected by this issue. Ruslik (talk) 19:34, 15 December 2019 (UTC)

Upload tool not working

Hi guys,

  • I'm trying to upload files in the last two days without success. The files seem to upload and then the sytem freezes while "queeing" or "processing". I tried with two different browsers and the result was the same. I also know it is not general because new files are being uploaded every minute. Thanks, Alvesgaspar (talk) 12:19, 15 December 2019 (UTC)
Tracked in Phabricator
Task T240698

Help required with captions

I uploaded three files of a butterfly, sucking nectar from a Buddleja. The pictures were taken during vacation and they seem interesting to me, because you can see the suction process continue in 3 images, even though the process was rather quick. (shutter speed was 1/8000 and continuous shooting was used). However, I don't know which butterfly it is (or if it even is a butterfly). Maybe someone can help me with the right titles.

Similar for the following images, although they don't show a process, but only a single butterfly each. I don't know anything of butterflies and whether they are scarce or common, but maybes the images below might be helpful. Is there someone who knows about butterflies who can give those images the right name? If it are images about very common butterflies, from which there are already images of similar quality on commons, feel free to delete them as well.

Koos ... 10:33, 13 December 2019 (UTC)

Can't do much today (on the phone & travelling) and my knowledge is limited but the first one is

Macroglossum stellatarum. Some others are Iphiclides podalirius L. and probably Argynnis paphia or similar species.--TFerenczy (talk) 14:39, 13 December 2019 (UTC)

  • (Edit conflict) @Koos Jol:
    • You can always try Category:Unidentified Lepidoptera.
    • Series of related images may be listed under | other versions of {{Information}} as a <gallery>.
    • Never, never upload files with temporary filenames — always use something that is minimally suitable: In this case Butterfly on Buddleja 1.jpg etc. would be acceptable both before and after a detailed identification.
    • Category:Buddleja or one of its subcats must be used in the relevant filespages, and/or (at least) "Buddleja" should be included in the description.
-- Tuválkin ✉ ✇ 15:03, 13 December 2019 (UTC)

I think number 8 is a Scarce swallowtail.

 

Qwerty number1 (talk) 17:05, 13 December 2019 (UTC)

Number 7 might be a fritillary butterflyQwerty number1 (talk) 17:11, 13 December 2019 (UTC)

Thanks for the useful tips and additions.
  • Image 4 is still undetermined. Maybe it's a moth. Google image search said it might be the Jersey Tiger Moth. If anyone can confirm this, I will request a name change.
  • For image 7, I added a deletion request, since there are much more images of better quality for this species.
  • For image 8, I requested a name change.
Koos ... 05:48, 16 December 2019 (UTC)

Service Temporarily Unavailable

In the last few hours I got this notice three times already:

Service Temporarily Unavailable

Our servers are currently under maintenance or experiencing a technical problem. Please try again in a few minutes.

This is bad, causing loss of editing work, as edits done with Cat-a-lot (ans some other gadgets) cannot be backed up loaclly, and even normal wikitext edits are cumbersome to back up locally. -- Tuválkin ✉ ✇ 00:45, 16 December 2019 (UTC)

Yeah its bad, but its even worse to use cat-a-lot under those circumstances. Best to retry another time instead of hammering the server!? --93.201.168.162 03:55, 16 December 2019 (UTC)
I think it's more of a question of what's causing this and how long might it last? — Huntster (t @ c) 04:14, 16 December 2019 (UTC)
OP clearly is not in a position to find out what's causing this, neither am I, so its best practice to wait and be patient (and do other stuff elsewhere in the meantime) instead of brute forcing things, just my cents.. --93.201.168.162 04:33, 16 December 2019 (UTC)
  • IP is clearly talking out of its rear end: OP refers to three times in the last few hours, that is, three times insterspersed among many normal edits, not three times in a row, obviously.
(Strange how IPs are often so much invested in, and informed about, the inner works of the project, as if they were actually well known editors or WMF workers instead… Is it only me or these IP edits that are not just random once-off content edits really send out a very creepy vibe?…)
-- Tuválkin ✉ ✇ 06:23, 17 December 2019 (UTC)

File:Nils Gustaf Örbom KBGF.013811.jpg

How do I add in the institution that the image came from? RAN (talk) 02:15, 17 December 2019 (UTC)

You should use {{Artwork}} instead of {{Information}}. Ruslik (talk) 18:46, 17 December 2019 (UTC)
I added {{Institution}} to the source field, which should be used in place of {{Collection}}. {{Photograph}} might be a better option than {{Artwork}} in this case, but neither is required. --Animalparty (talk) 01:03, 18 December 2019 (UTC)
Perfect thanks! RAN (talk) 02:16, 18 December 2019 (UTC)

Suppressing redirects for filenames with incorrect identification

According to the renaming guideline, suppression of redirects is allowed in these cases:

  1. To move recently uploaded files with an obvious error in the file name where that error would not be a reasonable redirect. For example: moving "Sheep in a tree.jpg" to "Squirrel in a tree.jpg" when the image does in fact depict a squirrel.
  2. To perform file name swaps.
  3. When the original file name contains vandalism. (Renaming criterion #5)

Last night I noticed that MPF moved 3 files I uploaded in 2016 for which I had an incorrect identification:

This is, in general, a welcome correction, and I very much appreciate MPF's efforts to ensure our images of animals are correctly identified/described. But in this case MPF suppressed redirects leading to this discussion, where it is clear we disagree whether incorrectly identified subjects qualify under the above criteria.

A file uploaded years ago may have been used off-wiki. Deleting the former filename breaks any links provided for attribution and may even point to a different file altogether if a new one is uploaded. MPF argues that deleting the redirect more effectively conveys to the file user that it was incorrectly identified. This presumes that someone can make sense of the deleted page, that "identity" is a clear enough edit summary to explain that it was misidentified, that nobody has uploaded a new file, etc. Most of all, it breaks attribution. Meanwhile, if the redirect remains intact, the attribution does not break and anyone clicking it will be taken to the correctly identified image.

Looking at the move log, there appear to be hundreds or thousands of examples of this, seemingly irrespective of file age.

In short, this seems to me like a clear example of why criterion #1 says "recently uploaded". What am I missing? — Rhododendrites talk |  22:09, 2 December 2019 (UTC)

I would argue that it is not just useful, but very important, to break links to incorrect names from misidentified imagery however long since uploading. With the number of files Commons has now, it is simply not feasible to review every file for identity within a tight time limit. While a misidentification could at times be deliberate misinformation (and thus classifiable as vandalism), in the vast majority of cases, it is a genuine error rather than deliberate malicious vandalism. Yet it is still misinformation, which resultings in confusion (for those who don't spot the error) and loss of trust in Commons as a reliable supplier (for those who do spot the error). Yes, deleting the redirect does effectively convey to the file user that a file was misidentified; not doing so does not notify them at all, so they will continue in ignorance of the file renaming, and continue promoting the error without knowing it (this is actually a problem within wikipedias, as well as outside). How many users of outside sites ever click through to see if the image might have been reidentified? My guess would be minimal - one in a hundred, if you're very lucky. And true that deleting might break links for attribution, but it also removes the erroneous image from the site it is being used in; attribution for something no longer there matters little. One would hope though that an obvious image disappearance would prompt the outside user to return to Commons to seek a new image to replace the missing one with. A rename with a redirect signally fails to do this. This is of course all relevant beyond just animals or plants; it matters equally if, for example a misidentified building or a misidentified mountain view gets used in tourist guides, and so on (not my area of expertise - but I'm willing to bet there are plenty of them on Commons too). - MPF (talk) 22:58, 2 December 2019 (UTC)
I think stability of longstanding links is generally more important than filenames being accurate descriptions. Descriptions need to be accurate descriptions (so they need to be edited when we have a correction like this), but that is a different matter. - Jmabel ! talk 02:18, 3 December 2019 (UTC)
@Jmabel: - but why should longstanding links be important, if they're being used wrongly? In a case like that, surely it is better to break the links, so that the identification error is no longer being promulgated? Do we really want a generation of people growing up thinking that sheep climb trees and have long fluffy tails, because a prominent website says so on the basis of a misidentified image from Commons? When I find a misidentified image, I frequently have to go round anything from one to 20 or more wikipedias replacing it with an accurately identified one, so that the misidentification is no longer being used (see randomly e.g. my contributions at Farsi wikipedia - it's virtually all 'replace misidentified pic' or 'remove misidentified pic'). I can't do that with external sites, but it needs to be done. - MPF (talk) 10:02, 3 December 2019 (UTC)
@MPF: I'm most concerned here with links from outside any WMF project that would be concerned with demonstrating that they had licensed the image accordingly, and who is to say that this image usage is wrong? Let's say someone had used one of these pictures of a duck to illustrate a children's story, or if a picture of a street in Manhattan proves to be on 48th when the old filename said 49th. We should not be breaking the link. - Jmabel ! talk 17:31, 3 December 2019 (UTC)
@Jmabel: - I'd think that's a vanishingly small possibility, at least in respect of the bird files I've been renaming (can't say for the street example). What is more typical of what I'm dealing with is commoner birds being labelled as rarer ones, sometimes as very rare species. There, the risk of the common bird being widely but wrongly used to illustrate the rarer one is much more likely. For one very recent example I dealt with, a photo of Batrachostomus moniliger from Thattekad in Kerala, India, had been misidentified as Rigidipenna inexpectata, an extremely rare species from 9,000 km away in the Solomon Islands with hardly any published photos anywhere (and certainly none with a free license). This photo had been put onto the latter's wikidata page, as well as about a dozen wikipedias (from all of which I removed it); more likely than not, as the only free image claimed to be of this rare species, probably widely outside the wiki system too. In a case like this, it is highly likely that erroneous information could have serious consequences for understanding of what the species looks like. - MPF (talk) 21:47, 3 December 2019 (UTC)
@MPF: I don't know about bird files in particular, but I've had newspapers, magazines, and miscellaneous websites reuse my pictures literally thousands of times, and usually the only clarity about license is a link back to Commons. If you break that link, you break the clarity about license. - 21:51, 3 December 2019 (UTC)
Yes, it can break links which may provide attribution and license information (as Wikipedia encourages). So omitting the redirect may create license violations on other sites. --ghouston (talk) 03:55, 4 December 2019 (UTC)
@Jmabel and Ghouston: - What's your point there exactly? If someone links to a file from Commons, and the file is moved without a redirect, the image disappears from the external site (as is desirable to prevent repeating a misidentification). So if the picture is gone, why should it matter about the license? You don't need a license statement for something that isn't there! - MPF (talk) 13:37, 4 December 2019 (UTC)
@MPF: This is a misunderstanding of third-party content reusers. If the image is used on a Wikimedia sister-project, then it is still hosted here on Commons. If an image is used by a third-party, like a news organization or a magazine publisher, the image will be re-hosted on their own site, and merely (ideally) link back to Commons in their attribution, as required by the terms of the license. This is the reason why we tend to err heavily on the side of preserving file redirects, even in cases where the redirect itself is patently meaningless. GMGtalk 13:46, 4 December 2019 (UTC)
@GreenMeansGo: - thanks; that helps clarify. Though the problem here is not redirects that are 'patently meaningless', so much as 'actively misleading'. Would it be possible to develop some sort of "soft" redirect that (a) preserves the licensing information, but (b) makes it more conspicuously clear that the original file naming was a misidentification and that the file is no longer directly accessible by the erroneous name? - MPF (talk) 15:21, 4 December 2019 (UTC)

@MPF: Yes, Template:SOFTREDIRECT already exists on Commons, and could probably be adapted to a special case template, like Template:SOFTREDIRECT-filename-error or something similar, where the template would specify something like:

This page is a soft redirect left as the result of renaming the file, where the original name was in error. This soft redirect has been left behind for the benefit of third-party reusers, who may have included the original file name in their attribution.

However, before we get to any of that, we should probably have a rough consensus that that's the kind of thing we should be doing, since this would amount to a change in Commons policy. Beyond that, the template would need to be adapted and then translated, which would be a non-trivial amount of work. GMGtalk 15:35, 4 December 2019 (UTC)

@GreenMeansGo, Jmabel, and Ghouston: - thanks; that looks excellent. I'd perhaps want to tweak the wording, but only very slightly, I'd been thinking something like

This image, taken by [Username] and released under [CC-BY...] license, has been renamed as [link to Newname], as the original name included a misidentification error. This soft redirect has been left [etc.]. [optionally also:] You may wish to review your use of this file if the change in identification affects your use.

- MPF (talk) 23:22, 4 December 2019 (UTC)

For the avoidance of doubt, yes, the "may have been used off-wiki" in my original post above is indeed concerning off-wiki sites (as in, blogs, websites, etc. not connected to Wikimedia) and the links they make to files to satisfy the terms of the license. i.e. some of the reasons we have very limited criteria for suppressing redirects. This approach of using a soft redirect addresses my concerns. No real opinion on the wording/style. — Rhododendrites talk |  23:51, 4 December 2019 (UTC)

  • It's beyond my technical ability to make such a template. My technical ability ended around ~2002 when I stopped reading books on how to make websites. But if we want to make this "a thing" then it probably should be put together as a concrete proposal at COM:VPP and not here, so that it get's maximum community input prior to implementation. GMGtalk 00:30, 5 December 2019 (UTC)
Regrettably beyond my technical ability too, but no doubt someone can do it. Yes, putting a proposal forward at COM:VPP sounds best, tho' unfortunately also something I'm not too brilliant at composing; I'll help put it together if someone can start with a framework of how these things are done - MPF (talk) 00:54, 5 December 2019 (UTC)

Just a note, before this is archived, that restoration of these redirects which were suppressed out of process shouldn't be contingent on the development of a template. The soft redirect seems like a perfectly reasonable interim solution, but we still have an awful lot of files for which any off-wiki attribution is still broken. — Rhododendrites talk |  19:22, 10 December 2019 (UTC)

Just a couple examples, looking at only the most recent suppressed redirects in the log linked above, returns these uses: this page uses the file now at File:Sri Lanka Frogmouth Batrachostomus moniliger, Thattekad, Kerala, India.jpg, but the attribution links is broken. Same with this page, which uses the file now at File:Ferry on the Bharathappuzha River, Ponnani, Kerala (241702776).jpg, also with broken attribution. — Rhododendrites talk |  19:40, 10 December 2019 (UTC)

@Rhododendrites: Though the first of those is still using the image wrongly, claiming it is what it isn't; a particularly serious case in this instance given the rarity of the genuine Solomons species - this is exactly what I was hoping to prevent by breaking redirects. That picture needs to be removed from there! MPF (talk) 15:14, 12 December 2019 (UTC)
I feel like you're still not getting the fundamental thing here: there's identification, and there's the license. Two separate things. Fixing identification is great. I have long appreciated your dedication to that activity. But you did so in a way that breaks attribution, operating according to your own criteria in direct conflict with the guideline, which isn't ok, regardless of whether people used the photo incorrectly. Whatever method you decide to use moving forward is fine, but we still now have people who licensed their photos with CC BY whose attribution is broken because of this approach. Perhaps there is a way to automated recreation of the redirects? — Rhododendrites talk |  16:05, 12 December 2019 (UTC)
@Rhododendrites: I take your point; we need to find some way of enabling the license link, while stopping direct access to the image itself. The soft redirect suggestion looks like that should work, is there any progress on getting it enabled? I've relinked the redirect to File:Ferry on the Bharathappuzha River, Ponnani, Kerala (241702776).jpg so that one works now. - MPF (talk) 15:00, 18 December 2019 (UTC)

What I believe is a similar discussion is at User_talk:VKras#Recent_moves. Suppressing redirects for long hosted files, and in the example case dropping unique identifiers from the files, is an easy mistake for many of the users that have been mass granted this right to make. Honestly, I think we should have a process for reviewing how users who are newly using this effective non-sysop right of deletion are using it in practice, and consider removing the right for many of these users, letting them apply for it if they have a case.

The amount of work needed for someone like myself that originally uploaded the files, to detect that it happened, to work out that the move without redirect is wrong, and to have to explain precisely and in a very polite way are acting incorrectly, is so tricky that I imagine that many are just letting it carry on even if they notice something wrong. Thanks --Fæ (talk) 19:31, 10 December 2019 (UTC)

Diminished quality of Commons search results

Tracked in Phabricator
Task T240404

Key quotes

This is breaking workflows at Commons and needs to be fixed/rollback the regression asap. Josve05a
This should be considered a project breaking change, and testing must be in place to avoid a breaking change as serious as this to reoccur. Fæ

The search API has suddenly (as of the last few days) become quite inconvenient and unhelpful. For example, previously I could search for "Performing arts" and, since there is no gallery page by that name, I would be conveniently redirected to Category:Performing arts. Now I am taken to a results page that encourages me to create Performing arts -- while offering no clues whatsoever that a category by that name already exists. I expect that this change will make it more difficult for new users to find what they're looking for. Was this done purposely and, if so, why? Lambtron (talk) 22:47, 10 December 2019 (UTC)

It is annoying. Under the previous method, typing "Category:Mammals of Asia" (or any category that already exists) into the search bar would bring you directly to Category:Mammals of Asia. Now it goes to a search page, informing me "There is a page named "Category:Mammals of Asia" on this wiki". No duh! Adding even one additional step or click is annoying and hinders efficient navigation. Hopefully this can be fixed, not some change we're forced to live with. --Animalparty (talk) 23:09, 10 December 2019 (UTC)
Oh, and it's probably related to changes to allow searching Depicts. The coming change was briefly announced here. --Animalparty (talk) 23:20, 10 December 2019 (UTC)
This has to be considered a major project breaking change and requires immediate rollback.
⚠ If you agree, please log in to Phabricator by clicking the tracked link above and add a token to T240404. --Fæ (talk) 23:40, 10 December 2019 (UTC)
  • The search behavior now after the change is not intended behavior, people should be sent to proper pages on exact matches (at least from the drop down) and not always search results. I've talked with the developers about the ticket, it's going to be sorted out and fixed. Keegan (WMF) (talk) 17:40, 11 December 2019 (UTC)
  • Until the bug is fixed that's affecting the drop-down and non-mainspace pages, there is an option in preferences that will restore the old behavior of search. I know it's never desired to have a visit to preferences to fix things back, but it is there:
 
I'll keep Commons updated when the patch is deployed. Keegan (WMF) (talk) 18:46, 12 December 2019 (UTC)
    • In fact, when you get to the results page, almost in the very center of the screen in bold it says, Help   Search categories   Show other tools. Click that link "Search categories" and you will get a list of categories with matching titles as the search result instead. Takes an extra click, but gives you both functions without having to mess with settings. ~ R.T.G 03:18, 13 December 2019 (UTC)

The Phabricator task was changed from Commons search broken to Default search on Commons does not list exact category name matches. This obfuscates the fact that this project's long-established search function was broken by a recent change, this change is not the "default search", this is a change that has not been agreed with the community. I have changed the title of the task to Recent change to search on Common has broken correct page returns for categories, templates, commons space, shortcuts, hopefully, the name of the task will not be subject to spin to reduce the appearance of the actual damage to this project that bad experiments with the search engine can create. This is a bug, a breaking change, not a "feature" or the "default" that us schmoes should stop complaining about. @AKlapper (WMF): who may wish to provide verifiable facts if we have the wrong end of the stick. --Fæ (talk) 17:07, 11 December 2019 (UTC)

@Fæ: its important that phab tasks are titled in a way that describes the problem. They need to specify how something is broken. They are generally not the place to pontificate about how the bad the breakage is (beyond perhaps describing in technical terms the scope of the breakage). The original title of "Commons search broken" is bad because it doesnt explain how its broken. The search feature can be broken in thousands of ways. Overly vauge bug reports are frustrating to developers-if i saw a title like that, my general assumption is that the rest of the report is probably going to be vauge as well, i am probably going to have to spend a bunch of time teasing out of the reporter what actually is wrong, so i would put it at the end of my todo tasks. You seem to think that aklapper's new title of "Default search on Commons does not list exact category name matches." belittles the issue by saying "default" but on the contrary when something that is default is broken, to a developer that is a much more serious thing. The default is what everyone gets-the default being broken is a serious matter because it affects all users (however i do agree having the word regression or something like it in the title would have been fine to denote that this is a new breakage). Bawolff (talk) 13:36, 12 December 2019 (UTC)
This is not a bug with the default search, this is a change that has broken the default search. Taking "broken" out of the title does not help to understand that this broke Commons, regardless of which technical vocabulary you subscribe to. By the way, can you explain what "not default search" is if "search" is too vague for Phabricator because there are other Commons search engines? --Fæ (talk) 13:54, 12 December 2019 (UTC)
A change that breaks something is a "bug", at least in how the term is used around wikimedia projects. I don't object to the inclusion of the word broken. Its a meaningless adjective because its so over used on phabricator (when half of all bugs have the word broken in it, the word becomes meaningless and is ignored), but it certainly isn't harming anything. Well i don't want to presume to speak for andre, I am almost certain the motivation for his change was primarily to add the part about how, non-main namespace exact matches arent happening, is the problem, and the removal of broken was more just to simplify something that isn't communicating useful info. Not default search would be if the issue only happened if you had some obscure preference or gadget enabled that the majority of users did not. Default just means that its the normal search that everyone uses Bawolff (talk) 16:30, 12 December 2019 (UTC)

Ack others. Very silly change. It's annoying and counter-intuitive. If I wish a search results' page I enter a keyword and press Enter. But if I see suggestion of the precise file/category name I'm looking for and I click on it, I certainly want to see this particular file/category, not some search results. In addition, after the latest MediaWiki update, now only a half (cut from the bottom) of my very upper toolbar (with "Preferences", "Watchlist" etc.) is shown. Really not nice. --A.Savin 22:32, 12 December 2019 (UTC)

I think that's the right thread for the issue I noticed... Until recently, if I entered COM:VP into the search box, I received this page directly. Now I get search results instead, which is rather inconvenient. Or COM:DR, for example, or my own user page User:Gestumblindi, I can no longer access them directly via the search box. Slightly annoying, though it's certainly just one click more.... Gestumblindi (talk) 22:13, 13 December 2019 (UTC)

I should read everything before adding my complaint... okay, I see the fix now and changed my preferences accordingly. Gestumblindi (talk) 22:19, 13 December 2019 (UTC)

Do we need a RFC to restore the default search functionality?

The response on Phabricator is that the default that the majority of volunteers expect, to be taken to the exact match you were searching for, be it a category, file, template or policy page, has been changed to be a non-default user preference in a new preferences tab for the site search. If you do not make those technical user preference changes then you will never be taken to the page you were looking for, instead it might appear on a list and you may be taken to it if you can find it and click on it.

Do we need a RFC to make the community consensus clearer as to whether this non-requested, non-agreed change by the WMF should be reversed? --Fæ (talk) 18:40, 12 December 2019 (UTC)

@Keegan (WMF): your summary above, posted a few minutes after this section was created, appears to contradict the meaning of "There's a user preference to restore the original behaviour. Sorry that we neglected to mention it in the original announcement of this change" which was posted on Phabricator. Which is correct? --Fæ (talk) 18:50, 12 December 2019 (UTC)

I don't know why you'd need an RfC, the problem with redirecting to results when trying to go to policy, categories, etc., is an accident and unintended behavior. The intended behavior is that searching for a simple mainspace-type term like "Dog" will take you to results page and not the gallery page. The rest of this in unintended and will be patched. The preference was put in for people who wanted all results, including the search for Dog, to go to exact matches. It's not meant to be the fix for this problem, Cparle and myself are pointing out that in the meantime you can use this preference as a workaround. Keegan (WMF) (talk) 19:07, 12 December 2019 (UTC)
@Keegan (WMF): Thanks for the Preferences tip; it restored the search behavior I'm used to and was easy to implement. Lambtron (talk) 22:04, 12 December 2019 (UTC)
Patch has been merged. I'm not sure when it will be deployed yet, but it's on the way. Keegan (WMF) (talk) 17:41, 13 December 2019 (UTC)
The fix is live. Mainspace name searches redirect to search results, all other non-mainspace searches or clicks in the drop-down will take you directly to the page. If you do not wish for your mainspace searches to go directly to the results page, the option in preferences to redirect to exact match when searching will restore the old behavior, the only thing that was intended to change to begin with. Keegan (WMF) (talk) 17:34, 18 December 2019 (UTC)

In search disambiguation? WikiData...

I just been searching for "Torre del Conde", a building in San Sebastian, Spain. In the drop down menu from the search box, I got the usual list of files with the matching titles, except halfway down the list was split into two lists, starting with "Torre del Conde (disambiguation)". So I right clicked it to open in another tab. It gave me no results instead searching for a WikiData item, something like &haswbstatement:P180=Q223134 ... So I checked exactly what I was looking for, San Sebastian, Spain,, back to the search box, list still split in two, but below the disambiguation is something like "Torre del Conde (Espana)" or "Torre del Conde (San Sebastian)". I click the correct one but instead of taking me to Category:Torre del Conde, I got another blank search result with the similar statement, &haswbstatement:P180=Q0012983 ... So I tested it in another window with a search term I knew would need disambiguation. Same blank result. No problem just pressing the magnifying glass to search normally. ~ R.T.G 00:24, 13 December 2019 (UTC)

  • I have to say: I literally cannot imagine the user who would consider this desirable behavior. - Jmabel ! talk 01:25, 13 December 2019 (UTC)
    • @RTG and Jmabel: It's searching depicts statements, seeing if there is a potential match for a file on Commons. If a depicts tag has not been created using the term yet, the results will be empty. There's likely better way to display that, in the meantime if you don't want these in the dropdown you can disable the preference "Search autocomplete suggestions based on structured data". Keegan (WMF) (talk) 02:34, 13 December 2019 (UTC)
      • I'm not talking about my ability to use it, I'm talking about the UI we are presenting to users or our site.
      • What possible reason is there to show, in a search on Commons, Wikidata items that are potentially usable in a "depicts" statement but, in fact, have never been used on Commons? - Jmabel ! talk 04:46, 13 December 2019 (UTC)
        • Depending on the search options, one gets potential matches from Wikidata too. I found selecting "tree heraldic figure" and ending up with Special:Search/haswbstatement:P180=Q811480, fairly interesting. Too bad that the Wikidata part doesn't output any images, e.g. d:Q19829249#P18.
          I suppose disambiguation item need some work, but they are generally odd in most contexts. Jura1 (talk) 05:02, 13 December 2019 (UTC)
          • I know little about programming. It seemed to me that it did everything very well until I clicked for the result. Instead of taking me to the result it searched for the Wikidata item related to it. I imagine that whatever part of the script that fetches from Wikidata, or the part that redirects you to the Wikidata place, has a non functional or an error. Other than that, what I know about programming is very limited.
          • I suppose what is going on here is not that you are trying to bring categories up the list of suggestions, but Wikidata items. Instead of returning text matches and title matches, you want to add more categories to the individual file, beyond what would be tolerated on Commons, for instance, if I uploaded a picture of a nice old man sitting on a step smoking a pipe with a labrador dog, you want to add terms for "nice", "old man", "nice old man", "old man sitting on step", "step", "sitting", "old man smoking pipe", "labrador dog", "old man with dog". ~ R.T.G 07:08, 13 December 2019 (UTC)
            • Correct. The WMF project to dump actual Commons content in descriptions and wikitext in preference for whacky techiques like invisible structured data and soft connections to wikidata has an actual outcome of craptastic semi-automated tags that are actually worse than how Flickrtags are used. Shame that in the "Agile", but actually not really Agile, world this is coming from nobody bothers with publishing, testing or user reviewing business cases and use cases. I presume that instead folks get gold stars for doing things and breaking things rather than real measurable improvement that end users actually want and can use. --Fæ (talk) 11:09, 13 December 2019 (UTC)
            • @RTG: No, I don't think anyone wants that kind of depict tagging. Such a file might depicts smoking, and maybe the dog and/or the old man, but that's probably about it. Commons isn't going to turn to using tags in the way you describe, I don't think anyone on the development team does either. You can learn more at and discuss the feature at Commons:Depicts. Keegan (WMF) (talk) 16:26, 13 December 2019 (UTC)

Gallery pages

@Huntster: Assuming you have been accurately quoted above, what's with "the creation of gallery pages should absolutely not be encouraged"? We have no policy or guideline to that effect, and on Phabricator, where we are reaching out mainly to technical people, this may mislead them. Phabricator is not the place to try to move policy. Tech-driven policy changes are exactly the problem here: a change to search driven by some techie's desires rather than Commons' decisions.

The reason I'm sensitive about this is that I've put a lot of work into certain gallery pages. Just for a few examples: Places of worship in Seattle, Romanian Orthodox churches in Bucharest, Seattle and the Orient. I personally think we need more well-curated gallery pages, not fewer, but Phabricator is not the place to fight over it. - Jmabel ! talk 16:14, 13 December 2019 (UTC)

Jmabel, so you would like me to remove my comment? Fine, I don't care. I maintain my opinion on them. — Huntster (t @ c) 18:08, 13 December 2019 (UTC)
The issue is creating a workflow for newbies that makes it appear as if galleries are the main thing for them to contribute to. That's definitely not the priority, and newbies can have great impact and understand a long more if they start off with improving categorization and creating relevant categories for topics they know about. Curation is only useful for topics of special interest and when done by someone with a solid grounding in how the project works. --Fæ (talk) 18:13, 13 December 2019 (UTC)
I certainly agree that creation of galleries is not the priority for newbies, and in fact is a far more suitable task for experienced users. - Jmabel ! talk 23:19, 13 December 2019 (UTC)
Galleries are useful if done right, but in my opinion many are not worth their existence. One often finds a scant 1 or two images of low to mediocre quality, an absence of higher quality images found in the respective category, redundant crops of the same images, and/or absence of any descriptive text. In such shabby state they serve to hinder rather than help casual users in find suitable images. The fairly recent creation of Template:Gallery page is a step in the right direction, but I think needs to be easier to create and maintain high quality Gallery pages from the start. Perhaps some type of drag and drop interface that encourages the addition meaningful captions can be developed . --Animalparty (talk) 00:37, 14 December 2019 (UTC)

PSF Tagging Of Unidentified Entities - Part 1

Hi Commoners,

I am currently in progress of finishing the COM:PSF projects and found there are some unidentified entities. Kindly rename this files if you know the name straight away.

1.   2.  3.  4. 


Thanks for anyone for helping out

Encik Tekateki (talk) 02:20, 14 December 2019 (UTC)

(1) is a line drawing of Salisbury Cathedral, compare File:SalisburyCathedral-wyrdlight-EastExt.jpg; (3) is an illustration for Tunic, compare [4] where the (or a) source is given. Lupo 22:11, 17 December 2019 (UTC)
(2) is an illustration for using a Tumpline. Lupo 12:14, 18 December 2019 (UTC)

Former/Destroyed and in/of

I was wondering if we might be able to get a consensus on categories with names like Category:Former cinemas in Seattle, Category:Destroyed buildings in Seattle, , Category:Demolished schools of Seattle that:

  1. "Former" means something that formerly served a purpose, and was repurposed. E.g. a "former school" is something that was once a school and then was used for some other purpose (or maybe mothballed, but not yet destroyed).
  2. There is no useful, maintainable distinction between "destroyed" and "demolished", at least as far as categories go. Even a building that is "destroyed" by fire typically involves some further demolition work. For categories, I would hope we could stick with "destroyed" consistently, and not try to make a distinction that will rarely be made accurately and precisely in any case.
  3. While I guess it is technically more correct to refer to, for example, "Demolished schools of Seattle" than "Demolished schools in Seattle" (since once they are demolished, they are no longer "in" anything other than history and memory), it is still not a very useful distinction, is hard for non-native speakers to grasp, and is in any case not made with any consistency at all. I'd really rather just have this be "Destroyed schools in Seattle".

I'm not necessarily saying we have to go through and rename all such existing categories accordingly (though it would be nice) but could we perhaps at least adopt this as a guideline, so that we can encourage that this be done consistently in the future, and with some hope to harmonize existing categories? - Jmabel ! talk 00:37, 17 December 2019 (UTC)

  • A "former school" is a school that closed down for some reason. The building(s) that it was housed in may or may not still exist. I agree that "destroyed" should be used in preference to "demolished". I agree that "Destroyed buildings in Seattle" is fine. --ghouston (talk) 02:46, 17 December 2019 (UTC)
    • So what would you go with? "Former school buildings"? If so, would we analogously want to use "former church buildings", "former theater buildings", etc.? Seems cumbersome to me: these categories are, as far as I can tell, always used for buildings. The only exception I can think of to analogous use is that we do distinguish "banks" and "bank buildings". - Jmabel ! talk 03:11, 17 December 2019 (UTC)

I agree that we need a consistent naming scheme and should redirect "demolished buildings in XXX" with the "Destroyed buildings in XXX" as demolition is planned and destruction is a much wider term. Furthermore if we can establish a general guideline on how categories should be named it would be well. I often come across inconsistently named categories and if we could all just establish consensus about when something should be the preferred name and then create pages like "Commons:Categories/Naming/Buildings", "Commons:Categories/Naming/Cities", "Commons:Categories/Naming/Animals", "Commons:Categories/Naming/Books", "Commons:Categories/Naming/Schools", Etc. And each of these can also be further subdivided. Our freedom of panorama pages are all wonderfully organised, if only we had such guidelines for category naming schemes. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 07:06, 19 December 2019 (UTC)

Enhancement to category tree

I've thought a long time how to improve browsing the category tree at points where a lot of subcategories are metacats (i.e. use Template:metacat). It may be a great visual aid to just change the category tree bullet from ► (U+25BA), which is the default for all categories now, to ▻ (U+25BB) for those nodes that toggle metacats. I'm unsure however where this change needs to be done and if it's easy enough to implement (category tree building code would need to know which cats contain metacat marker templates).

It may also make sense to set class="CategoryTreeBullet" and class="MetacatTreeBullet" in the output html accordingly. This way, user css can further style or eventually hide metacat toggle points if they are not interested in those.

If the page/category content is inaccessible or not accessible in a performant way at the place where the category tree is built, it may make sense to rethink/research if metacats should reside in the same namespace as 'normal' categories at all. Either a cat is a metacat or its not, so it may (??) make sense to use a dedicated ns for those, i.e. prefix Metacat: or similar. The caveat would be that it will need a lot of transition work to move existing metacats to the new namespace, but an advantage would be, that any code (template, lua modules, mediawiki, etc.) could easily find out and decide which type of a category it is about to process.

Please move this to a place more appropriate (phabricator!?), if you think this deserves to be pondered over at another place than the village pump. --93.201.168.162 04:33, 16 December 2019 (UTC)

It aims to improve usability (and configurability) of the category tree browsing feature. If you've used the category tree in places (i.e. have some year standing experience) you may have come across the phenomenon, that a category may list a lot of topic by this, topic by that categories lexicographically ordered before 'normal' subcategories. They are useful at times, but esp. if the list of these meta categories is large, it may be nice to have a visual marker in the tree where the normal subcategory entries start (which would be easy if a switch occurs from empty to opaque bullets at those points in a treelist).
Also, if metacat bullets had proper css class names, users that do not like the complexity involved could easily hide the metacat bullets from the tree using css. They'd have a more tidy experience browsing the cattree (but longer ways in that tree from a certain node x to node y, if that involved usage of metacat(s) otherwise present). It's nowhere near vital or critical feature (after all, there's the search box, so you do not strictly need the cat tree), but may be a nice to have, small improvement of an existing feature. --93.201.168.162 04:54, 16 December 2019 (UTC)
Why would users be less likely to be interested in looking at the portion of the hierarchy under a metacat? Certainly not my experience. - Jmabel ! talk 21:14, 16 December 2019 (UTC)

Category sort keys

The IP that started the thread above, has been sorting categories into Category:Bundesautobahn 38 using unconventional keys: ⌓ for bridges, ⌘ for interchanges, ⛶ for views(?), ⯊ for tunnels. Can't say I agree with this kind of sorting, not in the least because such unicode symbols sometimes do not render properly (such as ⯊, which for me is a block with some hex code). Next there is the problem of how symbols are interpreted. Besides, this introduces COM:OVERCATegorisation: Category:Thyratalbrücke‎ is now for example categorised under a subcategory of Category:Bundesautobahn 38 bridges and under Bundesautobahn 38 itself. Revert? --HyperGaruda (talk) 06:12, 18 December 2019 (UTC)

First I thought "hey, that's a clever way of grouping categories within another category". But that's what sub-categories are for. So yes, revert. --El Grafo (talk) 08:49, 20 December 2019 (UTC)

Youtube files not tagged for review

If you search insource:youtube -insource:own -incategory:Files_from_external_sources_with_reviewed_licenses -insource:pd -otrs -flickr you'll find 25k+ files. I spot checked a few. Most of them do need a review. One solution to this problem I can think of would be making a bot tag new uploads with LR. What do you think about this problem?--Roy17 (talk) 00:02, 16 December 2019 (UTC)

See Commons:Bots/Requests/YouTubeReviewBot. --EugeneZelenko (talk) 15:57, 16 December 2019 (UTC)
AFAICT the bot's tasked with reviewing tagged files. My concern is about all those untagged' for review.--Roy17 (talk) 17:32, 21 December 2019 (UTC)

File:Center of Kessenich.jpg

Tracked in Phabricator
Task T71311

Split from section Commons:Village_pump/Archive/2019/12#Service Temporarily Unavailable. --HyperGaruda (talk) 19:31, 16 December 2019 (UTC)

File:Center of Kessenich.jpg refuses to load, giving a similar error message as Tuvalkin's. Anyone else experiencing the same? --HyperGaruda (talk) 06:24, 16 December 2019 (UTC)

Seems the photograph is missing or there is some misconfiguration "File not found: /v1/AUTH_mw/wikipedia-commons-local-public.29/2/29/Center_of_Kessenich.jpg". Bidgee (talk) 06:28, 16 December 2019 (UTC)
Failing uploads are discussed above at #Upload tool not working, they are failing for already three days.--Ymblanter (talk) 12:29, 16 December 2019 (UTC)
Actually, this particular file was uploaded in 2008. --HyperGaruda (talk) 19:23, 16 December 2019 (UTC)
The file's revision history tells that Guanaco had already noticed and tried fixing the error two years ago, so it is probably unrelated to Tuvalkin's issues. I'll split this discussion off into its own section. --HyperGaruda (talk) 19:31, 16 December 2019 (UTC)
Dates back to 2014...--Roy17 (talk) 17:32, 21 December 2019 (UTC)

BSicon captions

I've been considering how to create captions for the 235K BSicons that we now have, and I've made a few attempts and tried to settle on a consistent format. (These have mostly been following caption vandalism by users of the Android app; I have 220K pages on my watchlist, so it happens every few days now.) Obviously, given the sheer number of largely generic images, it would not be ideal to have random users fill the captions in manually one-by-one, so it would probably be desirable to mass-add these using QuickStatements.

Captions
Image Current caption
  (BHF) BSicon, heavy rail (crimson), representing an open station on an open line
  (ehkBST+4 teal) BSicon, teal, representing a closed non-passenger stop on a smooth curve on an open elevated line
  (ekHSTACC2+r maroon) BSicon, maroon, representing a closed accessible stop on a smooth curve on an open line
  (etHSTACCr+1 carrot) BSicon, carrot, representing a closed accessible stop on a smooth curve on an open underground line
  (exdABZg3 grey) BSicon, grey, representing a junction between two closed lines
  (exhACCl olive) BSicon, olive, representing a closed accessible station on a curve on a closed elevated line
  (exhBST3+l ochre) BSicon, ochre, representing a closed non-passenger stop on a smooth curve on a closed elevated line
  (exhKINT2 black) BSicon, black, representing a closed interchange station on a closed terminating elevated line
  (exhSTRq+hk2 carrot) BSicon, carrot, representing a closed elevated line and part of a smooth curve on an adjacent closed elevated line
  (exkACC+1 jade) BSicon, jade, representing a closed accessible station on a smooth curve on a closed line
  (extACCq carrot) BSicon, carrot, representing a closed accessible station on a closed underground line
  (extHSTACC+4 cerulean) BSicon, cerulean, representing a closed accessible stop on a smooth curve on a closed underground line
  (extHSTr+1 purple) BSicon, purple, representing a closed stop on a smooth curve on a closed underground line
  (extKXACCa-Mq grey) BSicon, grey, representing a closed accessible station with cross-platform interchanges on a closed terminating underground line
  (exXBHF-Lq lime) BSicon, lime, representing a closed station with cross-platform interchange on a closed line
  (hTHSTACCx) BSicon, heavy rail (crimson), representing an open accessible stop at the crossing of an open elevated line over a closed line
  (KXACCxa-Rq yellow) BSicon, yellow, representing an open accessible station with cross-platform interchange on a line which is open in one direction and closed in the other
  (tKXINTxa-Lq black) BSicon, black, representing an open interchange station with cross-platform interchange on an underground line which is open in one direction and closed in the other
  (tvENDE teal) BSicon, teal, representing buffer stops on two open parallel underground lines
  (uetHSTACCe@g) BSicon, metro (dark blue), representing a closed accessible at-grade station and a tunnel portal on an open line
  (vENDEeq ruby) BSicon, ruby, representing buffer stops on two open terminating parallel lines
  (xhDST3+1 blue) BSicon, blue, representing an open non-passenger station on a closed elevated line
  (xhkHST+4 ochre) BSicon, ochre, representing an open stop on a smooth curve on a closed elevated line
  (xkINT3+l red) BSicon, red, representing an open interchange station on a smooth curve on a closed line
  (xtACCr blue) BSicon, blue, representing an open accessible station on a curve on a closed underground line
Detail Mentioned?
Uploader No
Upload date No
SVG type (e.g. Inkscape) No
File is a BSicon Yes
Explanation of what a BSicon is No
Set (e.g. purple) Yes
Whether elements are open or closed Yes
Structure (e.g. elevated) Yes
Line elements (e.g. corner) Yes
Aspect ratio (e.g. 1:4; "quarter-width") No
Geometry (e.g. k-curve) Partially (smooth/sharp curve; crossing; junction)
Orientation/position of elements (e.g. top left; "corner 4") No
Whether line elements terminate Yes
Object type (e.g. interchange station) Yes

For most uploads, to save time I've used the boilerplate description text "Image for BSicon diagrams" in the description field, which isn't especially helpful but gives the typical user of Special:Random some idea of what all these images are. The catalogue pages do have descriptions, but they're more useful for distinguishing the images than for actually describing them. The main previous attempt to actually describe these outside of the catalogue pages is w:en:Template:BS-alt, which is unmaintained and (very) incomplete.

I think it would be useful to workshop the captions further before adding them to more files. At the moment I'm mainly concerned about the level of detail and the wording, so it would be helpful if others post suggestions for how to improve these. Jc86035 (talk) 03:44, 21 December 2019 (UTC)

@Tuvalkin, AlgaeGraphix, Lost on Belmont, and Newfraferz87: Notification of this discussion; I chose not to post this on the usual WikiProject talk pages because it's generally relevant to the rest of the community. Jc86035 (talk) 03:44, 21 December 2019 (UTC)

Creator

Are we still supposed to be making creator templates like Creator:Laureys a Castro, or are we supposed to using "creator|Wikidata=" Are there advantages to each? With the actual template I can click on what_links_here and see how many entries we have. We lose that with the other method since we cannot perform a cross project what_links_here from Wikidata yet. RAN (talk) 02:14, 18 December 2019 (UTC)

@Richard Arthur Norton (1958- ) and Jmabel: , I agree that there are advantages to creating pages in creator namespace, like being able to use what_links_here or just being more readable by humans. Use of "creator|Wikidata=" is also fine, but for artworks with wikidata items a better solution is have all the data on Wikidata and source and wikidata ID in SDC. See wikitext of File:Godefridus Schalcken - Venus aan haar toilet in gezelschap van Amor - GK 306 - Museumslandschaft Hessen Kassel.jpg: it has an empty {{Artwork}} since all the fields are either in SDC or on wikidata. --Jarekt (talk) 20:55, 18 December 2019 (UTC)
Sounds good, I will go back and create the creator templates for the early photographers I have added. Do contemporary editors that add images they have taken get a Creator template? Most users upload under a Wikimedia ID and not their real identity, but if they wanted one, would that be acceptable? RAN (talk) 21:04, 18 December 2019 (UTC)
There are some guidelines at Commons:Creator. It is not a requirement that a person's Creator template have a corresponding Wikidata item, but in some cases a Creator template may not be warranted. --Animalparty (talk) 21:38, 18 December 2019 (UTC)
Creator templates and Wikidata entries are meant for historical figures and not Commons users. Plenty of Commons users created autobiographical templates and wikidata entries but it is discouraged. --Jarekt (talk) 22:18, 22 December 2019 (UTC)

Polish language help sought

Based on the explanation given at pl:Samochód_pożarniczy, can someone offer correctly spelled out names for the following categories under Category:Fire engines of Poland by designation:

-- Tuválkin ✉ ✇ 02:24, 18 December 2019 (UTC)

These are traditional designators according to now obsolete Polish norm PN-79/M-51300. Since 2000 coding system described in Polish-European(EU) norm PN-EN 1846-1:2000 is used. Anyway, because these are not abbreviations but codes, I am not able to propose any good sounding names in Polish (or English). But let's try:
  • GBM – samochód ratowniczo-gaśniczy ze zbiornikiem i motopompą,
  • GLM – lekki samochód ratowniczo-gaśniczy z motopompą,
  • GBA – samochód ratowniczo-gaśniczy ze zbiornikiem i autopompą,
  • GCBA – ciężki samochód ratowniczo-gaśniczy ze zbiornikiem i autopompą.
Dictionary: samochód ratowniczo-gaśniczy (or samochód gaśniczy) – firefighting vehicle; zbiornik – a (water) tank; motopompa – a pump with its own engine, moveable; autopompa – a pump powered by the firefighting vehicle's engine, not moveable; lekki – light; ciężki – heavy. --jdx Re: 05:25, 18 December 2019 (UTC)

Extracting audio from YouTube

I have found some videos on YouTube, whose audio tracks are out-of-copyright gramophone records. What's the best way to extract the hightest-resolution audio from the videos? I only have a few to do, so batch processing is not necessary. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 09:52, 18 December 2019 (UTC)

Example youtube-dl -f bestaudio --extract-audio --audio-format mp3 IsITU2RLEo4. Install youtube-dl here. --Fæ (talk) 10:32, 18 December 2019 (UTC)

Thank you. That's giving me

Install ffmpeg or avconv to fix this automatically.

ERROR: ffprobe/avprobe and ffmpeg/avconv not found. Please install one.

I downloaded the ffmpeg build from https://ffmpeg.zeranoe.com/builds/ but have no idea what to do with it, and its documentation is opaque.

The download page for avconv builds for Windows - http://builds.libav.org/windows/ - is even less helpful. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 13:43, 18 December 2019 (UTC)

Not in a position to advise on Windows. Presumably if you have a windows exe for ffmpeg, and put it in the same directory as youtube-dl, then youtube-dl will find it. --Fæ (talk) 14:56, 18 December 2019 (UTC)

the manual —TheDJ (talk • contribs) 15:01, 18 December 2019 (UTC)

So you're suggesting that someone installing software should at the very least read the file named "readme"? What's next - asking someone to try Google before asking their questions here? World's Lamest Critic (talk) 22:22, 18 December 2019 (UTC)
Been re-watching the IT Crowd? --Fæ (talk) 22:25, 18 December 2019 (UTC)
Congratulations on your apt choice of user name. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 23:09, 19 December 2019 (UTC)
Thank you! It's an inside joke between User:Neptune's Trident and myself. World's Lamest Critic (talk) 23:41, 22 December 2019 (UTC)

Images on OpenStreetMap

Why some images are showed in OpenStreetMap and some others not? I am talking about images that all have locations. I have noticed that some are using Template:Location dec and some Template:Location but the first is redirect to the second. Xaris333 (talk) 12:34, 21 December 2019 (UTC)

Anyone? I have uploaded many photos of places and I have added the coordinates, but no one is on OpenStreetMap. Xaris333 (talk) 18:48, 23 December 2019 (UTC)

maybe it is: Commons:Village_pump#Geogroup_problem --C.Suthorn (talk) 19:19, 23 December 2019 (UTC)

Flickr "distress" email

I recently received a fundraising email from Flickr suggesting that they were in dire need of contributions to sustain their existence. Although I view such communications with a jaded eye, it led me to wonder, why don't we just import everything there that is freely licensed, and then sort out here what we need to keep? That would basically preempt any situation in which Flickr suddenly becomes unavailable to us, with useful free content remaining there. BD2412 T 21:59, 21 December 2019 (UTC)

I believe it has been already imported?--Ymblanter (talk) 22:12, 21 December 2019 (UTC)
I don't think so. At least, I have found and imported Flickr images that at least do not appear to be in Commons on several occasions. BD2412 T 22:21, 21 December 2019 (UTC)
Not remotely. There are certainly tens of thousands of free licensed images of potential in scope usefulness that haven't yet been copied to Commons, possibly many more than that number. -- Infrogmation of New Orleans (talk) 22:50, 21 December 2019 (UTC)
  • Smugmug thought it was a good idea to change the business model — well, looks like it’s changing indeed. As for importing all their COM:L-compliant content, I have sympathy to the idea, but it would necessitate to be followed by massive scrutiny concerning scope. Ideally, Flickr content would be made available in Archive.ORG (or some such) instead, and we could pluck them there. -- Tuválkin ✉ ✇ 00:42, 22 December 2019 (UTC)
    • Archive.org isn't very searchable. A lot of images of possible value might be effectively lost due to the near-impossibility of finding them there. - Jmabel ! talk
      @Jmabel: For what it's worth, there's an API with which it's possible to query the Wayback Machine's index with a URL prefix (e.g. URLs with prefix "commons.wikimedia.org/wiki/Commons:Village_pump"). The Wayback Machine website uses this API with a preset limit of 100,000 URLs, but the limit can be easily avoided by omitting the limit parameter from the URL. It'll usually oblige unless you ask it to output an absurdly large amount of data, but I haven't deliberately tried to stress-test it (there doesn't seem to be any public documentation for this API). Jc86035 (talk) 13:52, 22 December 2019 (UTC)
@Jmabel and Jc86035: archive.org is much more than the waybackmachine. - Alexis Jazz ping plz 20:24, 22 December 2019 (UTC)
@Alexis Jazz: The main reason I might search web.archive.org (the Wayback Machine), instead of archive.org, is that most content from Flickr will be displayed in the Wayback Machine as a result of having been archived by either the Internet Archive internally, its trusted partners such as the Archive Team, or individuals using the Save Page Now service. Some (but not all) of these images would also be available at archive.org, but as part of compressed .warc files, and would be more easily retrieved using web.archive.org. (For example, these are the Flickr items uploaded by the Archive Team to archive.org; the vast majority of these were archived in January 2019 and uploaded over the course of the year. The images are stored in .megawarc files; the most recently uploaded .megawarc is a 17.7 GB file. There are indices for these (the .cdx files), which might help in ascertaining what URLs to look for in finding all images with compatible licenses; but there are also 31,440 items, so going through all of these might not be the most efficient way of looking through Flickr, especially since all of the images in this collection were archived during a very specific time period. Additionally, if you want to search through Save Page Now captures, the .warc and .cdx files aren’t public; the API would be a lot more efficient than going through the indices in any case.)
Images uploaded directly to the Internet Archive in their original format (or another format), as well as images included in .warc files not uploaded by trusted users, would be the only files which would be found at archive.org and not web.archive.org. I suspect this latter category would be much smaller, and would be difficult to search for due to the inconsistencies in user-generated archive.org item metadata. Jc86035 (talk) 09:10, 23 December 2019 (UTC)
For what it's worth, I have a lot of pictures on Flickr, many of which are also on Commons, but many of which are not. In some cases I made the choice not to upload to Commons specifically because copyright isn't "clean" (e.g. photos of copyrighted artwork, or buildings in Bucharest that raise issues because of Romania's lack of F.O.P. rights). It might be worth sucking them in, marking them with the year (if known) when copyright will expire, and leaving them to be revived someday.
Also: I have lots of photos on Flickr of bands performing; where I might post 100+ images on Flickr, I put maybe a handful on Commons.
I suspect this is typical of a lot of Flickr accounts, even ones where we have already uploaded a lot of images.
So far it's not clear they are threatening to close Flickr, and I can't imagine they would do so suddenly, but if they do decide to close it, then things like these might be worth having here for posterity. - Jmabel ! talk 01:01, 22 December 2019 (UTC)

I support the idea that we mass-import everything from Flickr and then add them to easily searchable categories for reviewing, these categories should typically contain as few images as possible and overlap with others based on authors and source location, these could then be properly categorised and reviewed. This of course will be the only contingency if Smugmug will find out that the only reason a no-name company like them could buy such a behemoth in the industry because it's not profitable at all.

If an author will be seen as a general bad source the author's entire maintenance category could be deleted (unless a few images have already been accepted). --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 19:32, 22 December 2019 (UTC)

Translations for sr-ec

Please create MediaWiki:Watchlist-summary-suggest/sr-ec (and/or MediaWiki:Watchlist-summary-suggest/sr) with "Оставите превод или предложите нову обавест" for Serbian Cyrillic translation.

And where to translate Config notices panel (Message topics and types, Select the topics you would like to get notifications about, New policies:, Request for Comments about new policies, substantial changes to or the adoption of new policies...), if possible? --Obsuser (talk) 20:00, 23 December 2019 (UTC)

VisualFileChange.js

I raised an issue on MediaWiki talk:Gadget-VisualFileChange.js#Can't Figure Out How to Change Previous Contributions. It said on the page, because it is so inactive I should mention here that I have added a post/topic. Jim Evans (talk) 23:01, 24 December 2019 (UTC)

Internet Archive

Hi. Can anybody here verify that Internet Archive may insert its own text into an archived page? This sounds bizarre but I think it is true as found in Commons:Deletion requests/File:Prince 1983 1st Avenue.jpg. The text "From the City Pages press archives" appears in the archived page only. The source says <div class="cred">From the City Pages press archives</div>. Thank you. -SusanLesch (talk) 15:20, 24 December 2019 (UTC)

It seems unlikely. Most likely the source page was updated at some point to remove the text. It appears in a 2016 archive at [5], which is missing the image, but not in a 2017 archive at [6]. Maybe it was a mistake and they fixed it. --ghouston (talk) 02:28, 25 December 2019 (UTC)
You're right it is unlkely and you came up with a reasonable explanation. Thank you very much! -SusanLesch (talk) 04:38, 25 December 2019 (UTC)

Licencing issue with Washington State Legislature photos

I recently came across beginnings of a conversation regarding the status and permission of File:Keith Wagnor Official.jpg. The image was tagged as {{No permission since}}, however, the uploader had originally claimed that the image was {{PD-author}} as it is a work of the Washington State government. While the executive branch through the WA Sec. of State has noted that images produced by the State Government are in PD ([7] and confirmed via OTRS Ticket:2011013110012254), the legislative branch via its Legislative Support Services apparently takes a slightly different view (http://lss.leg.wa.gov/ > Photography > Photo Usage and Integrity), where it states,

"Legislative photographs, including digital images, are provided as a courtesy or, where applicable, pursuant to Washington’s Public Disclosure Act (RCW 42.17). Where attribution is appropriate, credit may be given as, “Photo courtesy of Washington State Legislative Support Services.” The legislature maintains photographs as historical records and, as such, has a policy prohibiting their alteration or manipulation. Also the assigned name, number, and IPTC of legislative photographs may not be altered or changed."

This policy seems to contradict Commons Licencing policy in which the four freedoms (the freedom to use the work and enjoy the benefits of using it; the freedom to study the work and to apply knowledge acquired from it; the freedom to make and redistribute copies, in whole or in part, of the information or expression; the freedom to make changes and improvements, and to distribute derivative works) are the basic threshold for an image or media file to be hosted on Commons. The policy has been publicly online since at least 2014, but it is unknown since when it was in force prior to being placed online.
This issue seems to affect photos of Washington State legislators that are sourced from the Legislative website, and may also include File:Lisa Brown (politician).jpg, which has OTRS permission via Ticket:2010021210000445 from the photographed individual. While, according to OTRS, the individual has purchased the photograph, apparently according to the WA-LSS policy concerning the purchase of photos (http://lss.leg.wa.gov/ > Photography > Purchasing Photos):

  • A photo order form must be filled out. 5x7 prints $5 each; 8x10 prints, $8 each; digital JPEG image $5. Once a JPEG has been purchased prints may be made from that image. The photo order form can be found on the Legislative Photo Gallery site.
  • Members or staff wishing to utilize LSS photos for anything other than official legislative use must purchase them.

The question becomes whether the individual purchased the rights to the photo or simply a digital copy. A read of the WA-LSS policy would indicate that an individual may purchase, then, additional prints may be made from a copy, but no indication of transference of rights.
A slight different issue: a number of photos of Washington State legislators have been mistakenly marked as {{PD-USGov}}, however, such photos are evidently not the work of the US Federal Government. --Ìch heiss Nat ùn ìch redd e wenig Elsässisch!Talk to me in EN, FR, PL, GSW-FR(ALS). 12:51, 23 December 2019 (UTC)

  • If I go to the LSS photography and select a random photo (say a photographs related to a bill signing or of the Capitol building) and select the digital JPEG for purchase, it says that I have a "License: Royalty-free publication use and personal use" which I think would not qualify under the Commons licensing policy either. It says that legislative officials would need to directly contact the service so perhaps the member obtained an actual complete public domain license but without more details, then it seems like these images aren't compatible. I find that the best solution is basically a publicity one: we determine that these aren't compatible, start removing the images as per our policy and if asked by complaining politicians (as we will be asked) point to this discussion and suggest they get the LSS to be less restrictive. -- Ricky81682 (talk) 08:53, 25 December 2019 (UTC)
    • Seems to me that we would do well to contact some members of the legislature before going that route? Maybe Speaker of the House Frank Chopp and and Senate Majority Leader Andrew Billig? Would someone be interested in drafting a concise statement of the issue, worded for someone who is not engaged in Wikimedia? For example, we can't presume that they already understand our policies with respect to free-licensing. - Jmabel ! talk 17:46, 25 December 2019 (UTC)

Websites of the Congress of Deputies and Senate (Spain)

Hi everyone! I come from Spanish Café and [Village pump] at the suggestion of a user and to ask for help.

I am uploading photos of deputies, senators and politicians in general to complete gaps that arise with the creation of pages. I ask this question here because I wanted to verify the possibility or not of using images from the official website of the Congress of Deputies and the Senate of Spain.

  • On the website of the Congress of Deputies it seems clearer, since in the Legal Notice it states: "The information available on the website www.congreso.es is subject to reuse and is made available to the public without subject to conditions. The reuse of the contents must meet the following criteria: a) That the content of the information is not altered b) That the meaning of the information is not distorted c) That the source be cited d) That the date be mentioned of the last update. e) To follow a principle of public access and non-exclusivity." With that it seems that audiovisual material could be used in Commons, right?
  • However, on the Senate website I have more doubts. By accessing its Conditions of Use, sections 4 and 6, where, on the one hand, they authorize the use if it is for lawful purposes and without incurring vandalism but in section 6 it states: "The intellectual property rights of the website [ ...] are the property of the Senate, notwithstanding that, in general, the information contained in the website is subject to reuse under the terms set forth in these conditions of use, all the contents of the website (including, without limiting nature, symbols, trademarks, images, texts, audio, video, database and software contents) are the property of the Senate or of the service or content providers that, where appropriate, have granted the corresponding license or ceded exploitation of these contents to the Senate. The aforementioned contents are protected by the rules of intellectual and industrial property." From what I understand from there, the fact that the audiovisual material belongs to the Senate does not prohibit its reuse if it is for lawful purposes. Even so, I have doubts and I prefer to ask you before.

Regards and thank you very much for your help! Phalbertt (talk) 18:02, 27 December 2019 (UTC)

  • The CoD's statement of That the content of the information is not altered seems to be in contradiction to the fourth freedom (the freedom to make changes and improvements, and to distribute derivative works) per Commons licencing policy. As such, it would be not allowed on Commons. In the case of the Senate: the statement mentions that some copyrights are held by the Senate and others are licensed for use by the Senate, but makes no statement that works or other content are freely-licensed. To be allowed on Commons, licences must allow for all four freedoms: the freedom to use the work and enjoy the benefits of using it; the freedom to study the work and to apply knowledge acquired from it; the freedom to make and redistribute copies, in whole or in part, of the information or expression; the freedom to make changes and improvements, and to distribute derivative works).--Ìch heiss Nat ùn ìch redd e wenig Elsässisch!Talk to me in EN, FR, PL, GSW-FR(ALS). 19:33, 27 December 2019 (UTC)

Sandbox in file namespace?

Is there one for testing captions, depicts, imageannotation etc.? If yes, it should be mentioned in {{Test}}.--Roy17 (talk) 18:57, 27 December 2019 (UTC)

I would say just create File:SANDBOX.PNG and write a warning on the page. --GPSLeo (talk) 23:22, 27 December 2019 (UTC)

Slow edit war?

At Category:Alaska-Yukon-Pacific Exposition Baptist Headquarters Building I seem to have accidentally gotten into a slow edit war (see [8]) with User:ServB1. I tried discussing it on their user talk page and was ignored. Besides trying once to take it up on their talk page, I keep explaining my reversions in the edit summary, and they keep making essentially the same edit with no explanation. How can we resolve this? - Jmabel ! talk 18:14, 24 December 2019 (UTC)

You do not seem to have ever edited their user talk page.--Ymblanter (talk) 18:18, 24 December 2019 (UTC)
Oops! I had made the comment on the wrong user talk page. My apologies for that. Still, I was clear about my reasoning in the edit summaries. The mention of ServB1 in the first paragraph here should have notified them earlier today, so we can now maybe discuss here. - Jmabel ! talk 00:47, 25 December 2019 (UTC)
Hello Jmabel (talk · contribs). This is the first time I have seen the message. I had not seen your edits. Thanks for your help. --ServB1 (talk) 15:02, 30 December 2019 (UTC)

Slow/impossible upload

I got used to it, that uploading files can be incredibly slow sometimes. Today it is almost impossible for me. For more than 2 hours I try to upload about twenty files now and only ten made it to servers. For the others I just get Wikimedia Errors ("Request from - via cp3058.esams.wmnet, ATS/8.0.5 Error: 408, Inactive Timeout at 2019-12-27 13:39:08 GMT") again and again. Though I see at the recent uploads that it is possible. Any idea if it may be a problem with certain servers (I am located in Vienna, Austria) or if it is a problem with the old upload form I still use or what else could be the reason? Any help would be appreciated. --Tsui (talk) 13:52, 27 December 2019 (UTC)

I had an issue for one of my uploads earlier today; I had to abort and reatsrt the upload. I did not have issues with the reupload, or with uploads of my other files today or yesterday.--Ymblanter (talk) 19:11, 27 December 2019 (UTC)
  • I have noticed that I have had problems when I upload particularly large files sometimes. My router's upload speed is not the best, and if the upload cannot be completed within some unspecified timeframe, the upload gets aborted and I have to try again. I've gotten these things to upload eventually, however. Just had to try it many times (which is deeply annoying, I know). A loose necktie (talk) 03:31, 30 December 2019 (UTC)
    • You can use the stashed-upload-script. Either direct by activating it in preferences/gadgets (I think), or else: upload a small placeholder file, then go to the file description page, scroll down to "upload a new version", select "stashed", then use the slider to set the chunk size to a value, that suits your needs. --C.Suthorn (talk) 10:36, 30 December 2019 (UTC)

Accuracy vs. preserving titles from GLAMs

 

I've asked this before, but I've never really gotten a definitive answer: what exactly do we do with the title of an image like File:Palace Saloon at 2nd Ave and Pike St , ca 1904 (SEATTLE 1701).jpg, where the title came from a GLAM (in this case the University of Washington Libraries) but it is simply wrong: this is Seattle's Pike Street at the corner First Avenue, not Second. I've explained the discrepancy on the file page, and I've written an email to the library in question, but from my experience with them it is only 50-50 that they will ever correct the metadata on their site, including the title they gave the photo. Obviously, if they fix it, we can fall in line with them. I know we have a strong preference for retaining any title given by a GLAM in their archive. Conversely, if this were not from a GLAM we would certainly correct an actively misleading title. What exactly should we do here? I'm inclined to correct it, because someone skimming through a category would very likely be misled by the title into thinking the picture depicts a different location than it does, and that seems more important to me than preserving what a GLAM source says when the source is clearly wrong. - Jmabel ! talk 01:09, 30 December 2019 (UTC)

Rename it, unquestionably. We are not beholden to whatever esoteric naming conventions a GLAM happens to follow, and renaming our copy does not affect the link to the source. Pi.1415926535 (talk) 01:23, 30 December 2019 (UTC)
  • I agree 100%. Just 'cause they are getting it wrong doesn't mean we need to follow suit! They can use their own incorrect records for their own purposes, but we want our records to be searchable and correct for our site visitors. A loose necktie (talk) 03:28, 30 December 2019 (UTC)
    • OK. I'll do the minimal change here ("2nd" to "1st" and leave the redirect). Follow-up question: should we also change the "Title" in the "Photograph" template? - Jmabel ! talk 05:43, 30 December 2019 (UTC)

Jmabel and A loose necktie, this is not uncommon issue, so the infobox {{Photograph}}, which is used by File:Palace Saloon at 1st Ave and Pike St , ca 1904 (SEATTLE 1701).jpg, has fields to deal with that. The proper use would be to upload all the original descriptions into field original description field, which can have optional warning provided through field original description info, and a statement that the description is wrong or biased (if biased is set to "true"). That description should not be altered. Then the correct description goes into description field. See File:Bundesarchiv_Bild_101I-695-0412-05,_Warschauer_Aufstand,_Weichselbrücke.jpg and many other Bundesarchiv images for the proper use of both descriptions. On some occasions the descriptions diverge a lot, see here for example, and lead to Bundesarchiv altering their description. --Jarekt (talk) 16:52, 30 December 2019 (UTC)

Need some opinions for YouTubeReviewBot

Hi everyone,

There is an ongoing discussion at Commons:Bots/Requests/YouTubeReviewBot about creation of a LR category "Category:Files passed by YouTubeReviewBot pending human reviews", for files imported from YouTube and Vimeo. I was asked by one user to create the category, I don't think it's necessary at all. I am neutral on the proposal right now as I am afraid that it might be just another backlog. But there are some valid points like "Again you dont seem to understand limitations of your own bot. Archived pages do not archive the video. Your bot only checks whether a link has a good licence, but chances are the upload does not match the link or it contains extra material like another soundtrack remixed." which sounds reasonable. I’d like (to hear) your views @Commons:Bots/Requests/YouTubeReviewBot. Thanks -- Eatcha (talk) 05:57, 30 December 2019 (UTC)

Grain coupons of China

This category has been proposed for undeletion in 2020: Commons:Deletion requests/Files in Category:Grain coupons of China.

As far as I can guess, the idea is the coupons are from 1949 and enters 70 years later in public domain. If so, I think the two elements dubious.

More context: en:Grain rationing in China

What can we do to establish copyright rules on those coupons? --Dereckson (talk) 18:34, 31 December 2019 (UTC)

Per the article, the coupons were given post 1950s (possibly until 1978, from my quick read of the article):

In the 1950s, the grain rationing system was put in place, in which urban families were given grain coupons.
— en:Grain rationing in China

Fu Ying, former Chinese Ambassador to the UK, states that they were printed until 1993.
With regards to copyright, it's a bit tricky. Are they works of the Central Government? of the People's Bank of China? of the various provincial or regional governments? The first and, perhaps, the third are most likely in PD per Art. 5 of the 2010 Copyright Law. Work of the second (generally covering only banknotes and other currency) have restrictions, and are therefore not ok on Commons. In general China has a Life+50 rule for most copyrighted works (or Publish+50 for anon.). The question is when each of these coupons were printed. An additional question, if the files are photos, I have is when the photographs were taken and by whom, as photos of the coupons would be derivatives. --Ìch heiss Nat ùn ìch redd e wenig Elsässisch!Talk to me in EN, FR, PL, GSW-FR(ALS). 22:10, 31 December 2019 (UTC)
Copyright belongs to who printed them, basically any local govt agency in charge, so copyright lasts for publish+50. They were always printed just slightly ahead of the year/month when they were issued. Besides, most coupons employ simple text and shapes which do not constitute copyright. Only those with some kind of elaborate patterns or diagrams might be copyrightable.
Btw, only the photos should be undeleted (as they were published before 1969). The proper named cat is Category:Ration stamps of China.--Roy17 (talk) 00:44, 1 January 2020 (UTC)

Mistake via lingualibre.fr

Hello,

I made a setting mistake while recording audios on lingualibre.fr which impacted the language code of my last 1111 recordings ([9]). They are recorded in French, but I chose a wrong language (Finnish) in the Record Wizard. Can you help me to fix the files here?

Thank you very much!

— WikiLucas (🖋️) 01:38, 27 December 2019 (UTC)

@Jmabel: Hello, thank you very much for your advice! I installed VisualFileChange and I managed to change the language information of each file!
I will now ask for a mass rename on Commons:Bots/Work requests, but there is a part that might be tricky: if we take the file LL-Q1412 (fin)-WikiLucas00-rééclaircir.wav as an example, the bot will correct it into LL-Q1412 (fra)-WikiLucas00-rééclaircir.wav. The problem is that, for some of the 1111 recordings, there is already a page existing with the language "fra" (LL-Q1412 (fra)-WikiLucas00-rééclaircir.wav already exists, but needed to be changed). In those cases, we need to add the file LL-Q1412 (fin)-WikiLucas00-rééclaircir.wav as a new version of LL-Q1412 (fra)-WikiLucas00-rééclaircir.wav, like it is done using lingualibre (e.g. [10]).
Thank you for your help
— WikiLucas (🖋️) 20:49, 30 December 2019 (UTC)
I added all the files as a list here Category:Lingua_Libre_misleading_items_by_WikiLucas00_12.19, to simplify finding the problematic files. — WikiLucas (🖋️) 01:21, 3 January 2020 (UTC)

Is it ok to say this toupee is a toupee?

 
Don Dodge

Google exec Don Dodge wears a toupee. It is not subtle or hard to notice. Is it ok to add Category:Toupées to his images here? This is an obvious case, but I wouldn't want to get into some kind of edit war over who does or does not wear a toupee. I mean, is this a toupee in File:Peter R Orszag CBO official picture.jpg? I don't think it is, but someone else obviously does. Is there an etiquette? World's Lamest Critic (talk) 22:55, 18 December 2019 (UTC)

Hey World's Lamest Critic. It's fine to be bold and add a category that you think clearly belongs. If someone disagrees, it's not unlike Wikipedia. You should discuss the disagreement and reach a consensus. GMGtalk 23:07, 23 December 2019 (UTC)
Toupee or not toupee, that is the Question . . . (sorry!). @World's Lamest Critic and GreenMeansGo: - My suggestion would be to restrict Category:Toupées to images of toupees on their own, and create a subcategory of it [Category:People wearing toupées]. Then you could add that Don Dodge photo to that category, or, if he invariably wears one, add Category:Don Dodge as a subcategory of it - MPF (talk) 18:30, 30 December 2019 (UTC)
I don't like that "invariably" approach. We keep having people presume things like that and make a lot of work for someone later when it proved to be, in fact, variable. - Jmabel ! talk 22:09, 30 December 2019 (UTC)
I took your advice, MPF. Category:People wearing toupées now exists. For better or worse. World's Lamest Critic (talk) 17:55, 3 January 2020 (UTC)
And the result bears out what I warned about. Now Category:Thaddeus Stevens is a subcat of Category:People wearing toupées, but of the photos directly in Category:Thaddeus Stevens (I didn't look at subcats), by my count only 22 out of 47 at present are pictures for which that would be a reasonable parent category. - Jmabel ! talk 20:39, 3 January 2020 (UTC)
You were not wrong. I just switched categories where they related to people. Eight years ago, an IP editor added Category:Thaddeus Stevens to Category:Toupées. Feel free to get in touch with them to discuss why they did this. It is known that Stevens wore a wig, not a toupee. The wigs categories are worse. Category:People wearing wigs does not exist, but Category:Nude or partially nude people wearing wigs does, thanks to User:Neelix and his strange ways. World's Lamest Critic (talk) 00:04, 4 January 2020 (UTC)

Extracting audio from YouTube; redux

Some of you may recall a recent discussion, Commons:Village pump/Archive/2019/12#Extracting audio from YouTube, and my difficulties in using youtube-dl, as recommended there.

My sample target video is https://www.youtube.com/watch?v=ga5vpcH8wZM

I have revisited that, today, and managed to instal and use ffmpeg, which it apparently requires.

That is now failing with the error message: 

[ffmpeg] Correcting container in "John Henry & Blossom   Blossom's film scenario part01 and part 02-ga5vpcH8wZM.m4a"
ERROR: file:John Henry & Blossom   Blossom's film scenario part01 and part 02-ga5vpcH8wZM.m4a: No such file or directory

Can anyone help, please? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 16:26, 31 December 2019 (UTC) Pigsonthewing

Just download the video (assuming you are an expert downloader), use https://tools.wmflabs.org/video2commons/ to remove the video and upload the audio. Uncheck keep video. You must download the video on your computer then upload it to video2commons using upload file button, video 2commons is facing some issues with downloading YouTube videos.
  • Why are you getting this warning: various possibilities, listing 2 important ones.
  1. is the video really in your present working directory. In the worst case "is it deleted"
  2. if not in the working directory, specify filename with the path to file.

If you're on Windows you may find https://superuser.com/questions/440775/no-such-file-or-directory-in-ffmpeg , I am not copy-pasting the answers over here. But In my opinion Video2Commons is the best option, it uses ffmpeg. -- Eatcha (talk) 17:04, 31 December 2019 (UTC)

ffmpeg is called by youtube-dl, so the file it needs to act upon is (or, in this case is obviously not) wherever the latter puts it. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 20:11, 31 December 2019 (UTC)

Easiest option : use open source browser add-on, maybe https://addons.mozilla.org/en-US/firefox/addon/youtube_downloader_webx/ is what you are looking for. It's not easy to answer your question without access to the system you are working on. Sorry -- Eatcha (talk) 18:15, 4 January 2020 (UTC)

Logo for the California Philharmonic

I recently uploaded a logo for the California Philharmonic Orchestra and assigned it the PD-text-logo license, given its overall simplicity and my belief that it would not qualify for copyright protection. Still, I am unsure of my use of that tag. Would someone please take a look at the image and let me know what they think? I can move it to the English Wikipedia and make a fair use justification for it there if need be, but if it qualifies as public domain here on Commons, then all the better. Thanks!! A loose necktie (talk) 03:25, 30 December 2019 (UTC)

It is likely below ToO, in my opinion. Ruslik (talk) 18:38, 30 December 2019 (UTC)
There are a number of examples on COM:TOO United States that would lead me to believe that this image is above ToO. But that's just my assessment. On another note: regardless of whether I think it's above or below ToO, the image should be a vectorised image (SVG) rather than jpg, as the image looks distorted from the ones on the CaliPhil's website. --Ìch heiss Nat ùn ìch redd e wenig Elsässisch!Talk to me in EN, FR, PL, GSW-FR(ALS). 00:06, 31 December 2019 (UTC)
Or even in PNG like the original. --Ìch heiss Nat ùn ìch redd e wenig Elsässisch!Talk to me in EN, FR, PL, GSW-FR(ALS). 00:08, 31 December 2019 (UTC)
Done, per your request. A loose necktie (talk) 03:02, 6 January 2020 (UTC)

Provocatively wrong file names

The files below:

...are not in Israel, they are on the Israeli -occupied Palestinian territories. No country in the world accept that these places are in Israel, not even Israel claims that. I moved them to a neutral name (not including either Israel or Palestine), alas, now they have been moved back "at the uploader’s request", by User:Billinghurst and User:Richardkiwi.

I don't want to start an edit-war over this, I just want to say that I find the the present names extremely provocative, (besides the fact that they are factually wrong)..if a US visitor to Canada uploaded a picture, say from "Vancouver, USA", would that stay, as it was the "uploader’s request"?

Comments, anyone? Huldra (talk) 21:00, 31 December 2019 (UTC)

Commons:File renaming, the footnote on criterion 1 allows rejecting "disruptive or inappropriate" names, but that's at the discretion of a file mover. I don't know how you'd prevent it, since a file mover probably won't investigate the factual correctness of a criterion 1 request in great detail. Pointing out why you think the name is wrong on the files' discussion pages may or may not have helped. --ghouston (talk) 22:26, 31 December 2019 (UTC)
You have neither posted on the user's talk page or on the talk page of the images, nor did you let another more disinterested user move the files. And you did not ping @Djampa: on this discussion. It's a little frustrating to get called into these arguments where you haven't followed the basic steps.
That said, these seem to be clearly outside of Israel, and should be moved to a name without Israel in the title.--Prosfilaes (talk) 22:38, 31 December 2019 (UTC)
Sorry, User:Prosfilaes, commons is not my "home wiki", so I am a bit unfamiliar here. I pinged the two page movers above, and I hope they will undo their page-move. (And I can quite understand that not everyone is up-to-date on the intricacies of Middle Eastern policies....) Huldra (talk) 23:21, 31 December 2019 (UTC)
Hi, I changed it back to older versions. You have to discuss this with the uploader, this is not something the file movers must resolve.. - Richardkiwi (talk) (talk) 23:38, 31 December 2019 (UTC)
  •   Comment @Huldra: When I see a uploader request for a rename, and it is reasonably recent upload, then I don't go digging through the file history, especially when no talk page commentary. AGF with a face value assessment.

    Can I say that your approach of "just moving" to a name that you think is more accurate can be just as problematic and not assist others to know about issues. We have {{Fact disputed}} and talk page discussions that should be utilised so that the community can discuss these issues, and as flags to admins. This also gives the uploader an opportunity to express an opinion.  — billinghurst sDrewth 00:05, 1 January 2020 (UTC)

  • @Djampa: This conversation is about your uploads and rename requests, would you care to share your point of view. Thanks.  — billinghurst sDrewth 00:09, 1 January 2020 (UTC)
    @Billinghurst: well, that is the thing: I cannot see it is disputed, when not a single country in the world claims it.
Thank you for making me aware of the {{Fact disputed}} template, I have added it to the talk page of the file in question.
Note: I absolutely do not blame the page-movers here: obviously page-movers cannot be expected to be experts on the geography of the whole world. However, I would very much like to hear the justification from the uploader, and why s/he makes edits like this, Huldra (talk) 22:04, 1 January 2020 (UTC)
  • If I could suggest a compromise, file names don't absolutely need to be absolutely anything but unique. What if we just remove the reference to Israel or Palestine entirely? The titles would still be adequately descriptive for the purposes of building a repository of media for public use. GMGtalk 00:50, 2 January 2020 (UTC)
  • You are correct. In that case, I   Support moving back to the previous name. I don't think criteria 1 was ever intended to be license for uploaders to use file names that are potentially factually incorrect. Regardless, where there is a dispute regarding factually accuracy, and we don't actually need to make a decision one way or the other, the easiest thing to do is avoid doing so entirely, and use the name that everyone seems to agree is adequate. GMGtalk 13:40, 2 January 2020 (UTC)
    @GreenMeansGo: I don't think that there is any argument from me, though different optics. It was moved on the simple aspect of a recent upload that the uploader requested moved. Those get a sanity check from me (name and talk page), not a history review, nor an atlas lookup. At this point awaiting a short period to hear an opinion from Djampa seems reasonable.  — billinghurst sDrewth 07:31, 3 January 2020 (UTC)
@Billinghurst: It doesn't look as if Djampa intends to answer; they have edited after being pinged here, Huldra (talk) 20:41, 4 January 2020 (UTC)
@Billinghurst: Not only does not Djampa answer here, they go on making edits like this, and this today. Could someone please make this stop? Also @DannyS712: , Huldra (talk) 22:40, 6 January 2020 (UTC)
I have further moved one of the moves to a neutral name; mentioned the issue specifically on the user's talk page, and asked that they participate in this conversation.  — billinghurst sDrewth 23:01, 6 January 2020 (UTC)

Commons:Edit war

MOVED TO:
The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
This section was archived on a request by: --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 20:04, 4 December 2019 (UTC)

Why isn't this section getting archived? --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 19:43, 7 January 2020 (UTC)

Happy Public Domain Day!

Here are some things entering the public domain in the next several hours: https://web.law.duke.edu/cspd/publicdomainday/2020/ —Justin (koavf)❤T☮C☺M☯ 06:29, 31 December 2019 (UTC)

US works from 1924. And for EU/many countries, works by authors who died in 1949 or before, no? -- Infrogmation of New Orleans (talk) 07:19, 31 December 2019 (UTC)
Additionally, someone needs to change the text of pages such as Special:UploadWizard to "1925" and stop making errors if you upload something from 1924. —Justin (koavf)❤T☮C☺M☯ 11:36, 31 December 2019 (UTC)
Presumably, we also have some "1923" templates ({{Pd-1923}}, for example) that need to be updated? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 15:54, 31 December 2019 (UTC)
For the Commons:WikiProject Public Domain/German stamps review page, the talk page includes a topic, "'Review procedure for 2D reproductions of stamps' references 1923 and {{PD-old-auto-1923}}," that may be relevant. Thanks. --Gazebo (talk) 07:19, 2 January 2020 (UTC)
I had to reset the undeletion category to a later date in about a half of the deletion requests I reviewed due to URAA. Please be careful.--Ymblanter (talk) 21:28, 2 January 2020 (UTC)
  • I was looking at English Wikipedia's Rhapsody in Blue, which in the United States among the most famous 1924 works now in the public domain. I care less about this specific work than the general case, but I was thinking of how to plan to get media like this into commons in free versions. The image of the sheet music has a non-free license tag with no date metadata, so there is no way to automatically detect that this file should be free. I posted on the talk page there to recognize the occasion. Eventually and maybe soon we should plan an intervention at scale, because getting an entire year of media annually is a large new collection to manage. Blue Rasberry (talk) 16:43, 7 January 2020 (UTC)
  • @Bluerasberry: I don't think there is anything transformative or sufficiently original about someone's particular transcription of sheet music to make it copyright-able. But in principle, your question is a good one: having a project here to identify media that are about to be in the public domain and find ways to deliberately upload, catalogue, and use them is a wise idea. —Justin (koavf)❤T☮C☺M☯ 02:52, 8 January 2020 (UTC)
--Gazebo (talk) 05:49, 9 January 2020 (UTC)

caption -suggested edit

to the file File:FFF Frankfurt 2019-05-24 043.jpg a caption of "Frankfurt" was just added. Edits like that I have seen before. I see a number of problems:

  1. This edit suggester picks one file from a category, where all files of the cat need to get the same or a similar caption
  2. the suggestion is very poor. in this case a caption of "Global climate strike, Frankfurt/M, Germany, May 2019, FridaysForFuture" could be suggested from the cat alone
  3. wrong or poor captions are obviously not monitored
  4. sooner or later this bad captions will be translated or autotranslated to other languages
  5. I still do not know what exactly the captions will be used for? (what role do the play in Structured data? "human language unstructured"?)

--C.Suthorn (talk) 07:04, 21 December 2019 (UTC)

I see hundreds of captions added haphazardly to my uploads. They vary from poor to misleading or vandalism, and are never fixed. They are a pointless waste of volunteer time that could be spent improving actual descriptions and translations.
Please don't waste your time. --Fæ (talk) 08:50, 21 December 2019 (UTC)
@Fæ and C.Suthorn: In general I try to fix or at least revert them (see previous section), though clearly at the moment no one is really patrolling these edits. That said, according to Special:Tags there have only been about 12,000 of these edits so far, which is a little less than I expected. Jc86035 (talk) 12:02, 21 December 2019 (UTC)

Wow, those really run 50%+ useless or worse. - Jmabel ! talk 17:07, 21 December 2019 (UTC)

Maybe threshold for autoconfirmed should be raised to 10 edits. (Why does commons not require 10 edits in the first place?) And then this suggestededit thingy should be limited to autoconfirmed.--Roy17 (talk) 17:32, 21 December 2019 (UTC)
Before this vanishes to archives: @Keegan (WMF): --C.Suthorn (talk) 06:08, 24 December 2019 (UTC)
@Roy17: I've been thinking about that as well, but I don't know how to create a proposal for that without it getting voted on. @Majora: I really don't know how to work like this. - Alexis Jazz ping plz 19:38, 1 January 2020 (UTC)

When I track edits for files in a category that I recently been uploading files to, I have found that most of these edits are unhelpful and by new users. I have reverted them. However, because we can only see edits in the past 30 days in related changes, I cannot find and revert more such tentative edits by new users. Is caption edits by new users unhelpful common or specific only to this category? I also wonder how so many apparently non-Chinese users reach to such pages?--維基小霸王 (talk) 15:52, 1 January 2020 (UTC)

see Commons:Village_pump#caption_-suggested_edit ">50% of captions are useless" (@Keegan (WMF): ) --C.Suthorn (talk) 16:27, 1 January 2020 (UTC)
As a feature does not need any wikitext knowledge and is designed for mobile use this tends do become used by new users and for spam. --GPSLeo (talk) 18:15, 1 January 2020 (UTC)
I think allowing not-logged in users to edit those has been creating problems in much greater proportion than anything useful. (Many seems clear vandalism or silliness, others seem to think it's a search box.) If we're going to continue having the "captions", I'd think it would be better to restrict editing it to logged in users. -- Infrogmation of New Orleans (talk) 18:43, 1 January 2020 (UTC)
I patrol RC a lot and I would say that in this area anonymous users cause less harm (yeah, I said it  ). Registered users add much, much more captions than anonymous users and, what is unavoidable, significant part of them are just crap. Although you're right, "signal to noise ratio" or "not crappy to crappy captions ratio" is worse in case od anonymous users. The same applies to other structured data. Anyway, I think that editing should be resticted to autoconfirmed users. --jdx Re: 10:31, 2 January 2020 (UTC)
@C.Suthorn: Thanks for the ping, I've been offline the past two weeks. Looking into it, it looks like these specific caption edits (with the suggested-edit tab) are coming from a feature in the mobile apps; these are not built by the Structured Data team. I'll pass along the potential problem and concern to the mobile developers. Keegan (WMF) (talk) 18:52, 6 January 2020 (UTC)
Actually it isn't about structured data. It is about "mobile users". When you see an anonymous edit tagged with Mobile edit Mobile app edit you can revert it in the dark. I bet there is 98% chance that it will be a good revert. Registered "mobile users" cause less harm, but still, significant part of their edits have to be reverted. This is what happens when one tries to attract an average Internet user (let's face it: a moron). --jdx Re: 23:06, 6 January 2020 (UTC)
I have all national flags on my watchlist and while sometimes their caption edits are obvious nonsense, relatively often people will remove the English caption and add the same caption in English but as another language, which I believe is a good faith edit prompted by some flaw in the design or unclear description be it on mobile or desktop. Diff of the latest example--TFerenczy (talk) 10:29, 7 January 2020 (UTC)
@TFerenczy: thanks for that example. @Johan (WMF): here's a reference edit for consideration. Keegan (WMF) (talk) 17:56, 7 January 2020 (UTC)
Thanks TFerenczy, very useful and much appreciated. Everyone else: I'll read through this and summarise it for the relevant app team. /Johan (WMF) (talk) 06:25, 10 January 2020 (UTC)

  Info Merged #Most caption edits are unhelpful with this thread. - Alexis Jazz ping plz 20:00, 1 January 2020 (UTC)

  Comment I've said it before and I'll say it again: we should get rid of captions. It's a stupid idea. Bloody useless even. We can either ditch them entirely or rename them to represent descriptions for the visually impaired from now on. (Yes, we can actually do that) - Alexis Jazz ping plz 20:11, 1 January 2020 (UTC)

Good idea. I think caption can be merged with description since they are basically the same thing. Easier addition/modification of description can be implemented. I hope users would be able to add or change description simply by selecting a language, typing something on the description page and then clicking "save", just like in wikidata. If new users make a lot of unhelpful descriptions, additional procedures like preview may be implemented.--維基小霸王 (talk) 07:54, 2 January 2020 (UTC)
If captions continue to be so limited in length, cannot include links, and cannot include images, then they cannot be merged with description. - Jmabel ! talk 16:11, 2 January 2020 (UTC)
The difference between captions and descriptions is that captions live in SDC and descriptions in Wikitext, and by not allowing links, images or supper long entries, they are predictable. So in the future I should be able to do a SPARQL query to display bunch of images based on some criteria and present them as a gallery with captions underneath, or MediaWiki API will be able to reliably provide clean captions. --Jarekt (talk) 18:00, 3 January 2020 (UTC)
Retrieved from "https://commons.wikimedia.org/w/index.php?title=Commons:Village_pump/Archive/2019/12&oldid=516123708"