This website does readability filtering of other pages. All styles, scripts, forms and ads are stripped. If you want your website excluded or have other feedback, use this form.

Commons:Village pump - Wikimedia Commons

Commons:Village pump

From Wikimedia Commons, the free media repository Jump to navigation Jump to search

Shortcut: COM:VP

Community portal
introduction Help desk Village pump
copyrightproposalstechnical Administrators' noticeboard
vandalismuser problemsblocks and protections ↓ Skip to table of contents ↓       ↓ Skip to discussions ↓       ↓ Skip to the last discussion ↓ 🌐 Village pumps for other languages COMMONS DISCUSSION PAGES (index)

Welcome to the Village pump

This page is used for discussions of the operations, technical issues, and policies of Wikimedia Commons. Recent sections with no replies for 7 days and sections tagged with {{section resolved|1=--~~~~}} may be archived; for old discussions, see the archives.

Please note:


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

Purposes which do not meet the scope of this page:


Search archives:


Start a new discussion

Broadwick St, Soho, London: a water pump with its handle removed commemorates of Dr. John Snow's tracing of an 1854 cholera epidemic to the pump. [add] Centralized discussion See also: Village pump/Proposals • Archive
Template: View • Discuss  • Edit • Watch

Contents

SpBot archives all sections tagged with {{Section resolved|1=~~~~}} after 1 day and sections whose most recent comment is older than 7 days.


January 29[edit]

Date categorising photographs (and videos)[edit]

Hello, I have done my 5 minutes of work to help out with categorising and sorting photographs by date (mostly concentrating on countries that were untouched before, to avoid stepping on somebody's toes too much). I thought I would describe what I have done to bring some stuff to attention and maybe get some constructive comments on what to do better.

Here is how I envision we could lay it all out:

LevelGlobalTemplateLocalTemplate DayCategory:Photographs taken on 2020-01-29 {{Photographs taken on navbox|2020|01|29}} Category:Russia photographs taken on 2020-01-29 {{Russia photographs taken on navbox|2020|01|29}} MonthCategory:January 2020 photographs {{PhotographsYearByMonth|2020|01}} Category:January 2020 Russia photographs {{countryphotomonthyear|Russia|2020|January}} YearCategory:2020 photographs {{PhotographsYear|202|0}} Category:2020 photographs of Russia {{countryphotoyear2|Russia|2020}} DecadeCategory:2020s photographs {{PhotographsDecade|20|20|21st}} Category:2020s photographs of Russia {{countryphotodecade|Russia|202}} CenturyCategory:21st-century photographs Category:21st-century photographs of Russia {{countryphotocentury|Russia|21}}

There already existed two templates that categorised into this tree: {{taken on}} and {{according to Exif data}}. I have also made {{taken in}} conform to that, but it categorises into categories broader than day. I have also written User:Gone Postal/prefill.js, which fills out the template into the edit textbox when the appropriate category is opened for edit (but does not press submit).

Right now only the day categories are more or less standard, the funny part is that they all use different template, but the is little disagreement between them. Everything else is a mess of templates that do the same thing.

Of course, "the" countries (i.e. countries which start with "the") create difficulty (Category:January 2020 United Kingdom photographs is inside Category:2020 photographs of the United Kingdom). I believe an approach can be to create {{country article}} which would add articles to countries that need them when they are used as a noun in a phrase.

Any better ideas? ℺ Gone Postal ( ) 12:46, 29 January 2020 (UTC)

I'm not sure it's worth doing this right now - Commons:Structured Data should mean that you can just run queries to find the different sets of photos when the project is a bit further along. Thanks. Mike Peel (talk) 14:07, 29 January 2020 (UTC)
  • Mike Peel, it would be really super if you stopped spamming each and every discussion about Commons categorization with a plug to your pet project. If structured data is so great, go work on it and leave us to work on the category tree. -- Tuválkin 15:31, 29 January 2020 (UTC)
@Mike Peel: Even if and when the Structured data project is further along, how does one "just run queries"? CSD seems like a pet project championed by (and tailored to) a small group of programmers and not the general user of Commons. Everything on Commons:Structured data seems to involve how the user can feed the beast, not how the beast can serve the user. If I volunteer my time to add a million captions and "depicts" statements, how do I or other users efficiently reap the benefits? --Animalparty (talk) 21:22, 31 January 2020 (UTC)
@Tuvalkin, Animalparty: SDC isn't a 'pet project' (and it's definitely not mine!), it's a fundamental rewrite of the MediaWiki code that Commons runs on. A key part of it is that you can search for relevant content using queries - such as "photos taken on this day". The software doesn't seem to be quite there yet ([sdcquery.wmflabs.org] exists but doesn't seem to be operational yet), but you can look at example Wikidata queries at the query examples to see what would be possible here in the future. But don't mind me, I'm just getting on with things. Thanks. Mike Peel (talk) 22:06, 31 January 2020 (UTC)
Those links and examples are helpful, but the problem with "just run queries" is that it assumes one knows how to write the relevant code. SPARQL is a language not understood by casual media users. It's like saying "just clone the DNA" or "just build a machine" or "just translate the original Egyptian". Browsing Category:Greece in the 1990s is easier than learning Greek. Wikidata is certainly useful, but until Commons and Data fully recognizes its cognitive biases and becomes more user-friendly, the fruits of Wikidata/Structured Data will remain out of reach for most users. --Animalparty (talk) 22:27, 31 January 2020 (UTC)
Thank you for the reasoned reply - I agree with you. Thanks. Mike Peel (talk) 22:39, 31 January 2020 (UTC)
@Animalparty: You’re right of course, and definitely something the few of us who learnt their way into Sparql should keep in mind. I think the future is not in everyone learning Sparql, but in having nice front-ends which write the underlying code for you. VizQuery is one example that helps writes queries ; Crotos or OpenArt Browser help browsing artworks in a (IMO) very pleasant way. I can well imagine such tools covering 99.9% of the cases.
(and yes, for the last complicated 0.1% one might need Sparql. For what it’s worth, I have done many many Sparql workshops in the past few years, and I must say, many people quickly grasp the basics − well enough to take an example query “depicts cats in 2002” and tweak it for their needs into “depicts dogs in 2016”).
Also, many discussions (not this one) around finding things in the category tree go “just do a Category intersection/deep category traversal” − using something like Petscan is not exactly something easy either − it can be learnt of course (just like Sparql ;-) but I’m not convinced the average Commons would find that easy :-).
(Regarding “the docs are about adding data, and not about the benefits” − I had not thought about it and I think that’s totally fair, thanks for pointing it out. We definitely need to improve the docs on that regard)
Cheers, Jean-Fred (talk) 23:28, 1 February 2020 (UTC)
@Animalparty: With regards to If I volunteer my time to add a million captions and "depicts" statements, how do I or other users efficiently reap the benefits?, there's a user preference to get autocomplete suggestions using structured data. When this is selected, depicts statements appear below the usual suggestions when using the Commons search box on the top right (left side if you use the MonoBook or Modern skins; it's the search box you get when you press Alt-Shift-F). Unfortunately, those suggestions don't appear to show up on Special:Search, and the actual search query syntax used when selecting a suggestion is pretty esoteric, but it's a start. clpo13(talk) 00:12, 1 February 2020 (UTC)
I am not sure if that was the point and you aware of it or not but there's now a duplicate category tree without the for (the) Czech Republic (see Category:2016 photographs of Czech Republic, Category:2016 photographs of the Czech Republic). With the risk of opening a can of worms, some parent categories contain Czechia. :)--TFerenczy (talk) 16:11, 29 January 2020 (UTC)
  • Yeah, I have tried threading very carefully when it comes to the territory of the Czech Republic. Another thing that I have just noticed is that Indian contributors have chosen to create categories for days, and then to map them away from "photographs on" categories, however, they still had categories for photographs based on centuries. I would want to go and change that, but I don't even know a single contributor in that area. ℺ Gone Postal ( ) 12:59, 30 January 2020 (UTC)
  • This is a really good idea, and concerning Mike Peel's comments, I really hope that Structured Data on Wikimedia Commons (SDC) will do this, but unfortunately SDC won't utilise the existing category infrastructure so having "a dual system" with bot structured Wikidata-like data and traditional MediaWiki categories should be preferred until Structured Data on Wikimedia Commons can create its own infrastructure (or until Wikidata will better integrate with Wikimedia Commons). These categories will make things better for copyright violation hunters and those who want to categorise images based on geography. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 19:54, 29 January 2020 (UTC)
  • Here are some interesting things that I can report on:
    1. I have noticed that several countries, not just India have been doing something very strange thing when it comes to categorising photographs by month. Specifially they do not add country-photo-by-month category into country-photo-by-year, but rather directly into country-by-year. Russia also does something like that (how did I miss that?). So it is probably beneficial to create something along the lines of {{Country photographs taken on|country name}} which can take place of hundreds of individually created templates. For the most part it will be a direct substitution, but in some cases a little work will need to be done.
    2. One large reason why some countries might have not wanted to use generic approach is that multicontinent countries didn't work orrectly due to a bug in {{continentbycountry}} which stopped it from generating correct output for multicontinent countries. I have fixed that bug and it now works as expected.
    3. Another large problem is the "the". However, I have edited all the templates making use of {{country label with article}}, which uses already created by others {{country label}} (many thanks to Joshbaumgartner for their work on that useful template). Unfortunately, now that this has been added in the next few hours we will have tons of pages that get recategorised, and the category trees will need to be recreated. But that is life.
    4. I have noticed that there are some prolific photographers, who have created their own templates, which are used in place of {{information}}. See User:Voice of Clam/Information or User:A.Savin/Photo. Luckily most people, who bother to create their own templates are pedantic enough to also categorise their content so that it is easier to find. Thus it is something positive. (Thanks @Voice of Clam, A.Savin: and others).
    5. Many thanks to RudolphousBot, which is helping out in some of the categorisation. However, rather than adding {{taken on}} it is manually categorising pages. @Rudolphous:
    6. German users have started categorising their photographs into sub-country categories. Personally I believe that it is way too much, and will probably not use my energy to help out with that, but it is something that needs to be taken into account, in order to not start edit wars over a non-issue. I do think that adding cat=no and then categorising is silly (@XRay:) but at the end of the day, it is a problem with current tools, such as Cat-A-Lot, which are not aware of {{taken on}}/{{taken in}}. So I do think that it is possible that there will be accidental stepping on each other's toes, but I am carefully avoiding most of the German subcategorisation for now.
    • Hoping to hear some more feedback, and maybe ideas on how to approach diverse communities. ℺ Gone Postal ( ) 05:34, 1 February 2020 (UTC)
      • adding cat=no and then categorising is silly - interesting statement. I've seen a number of attempts with the date categories and categories in templates over the years. Sorry, but I don't think my way is silly. It's a result working with less complications. BTW: IMO it's not only Germany with deeper categories, it's for example the Netherlands too. I'm sometimes support a deeper level because of too much edits of other people forcing this kind of date categories, but I always support the "... taken on ..." categories. It should be accepted to do this without templates. -- There were a lot of discussions within the last years. There are some very eager users pushing the date categories. And not everyone takes part in discussions. --XRay talk 07:17, 1 February 2020 (UTC)
      • For your further research: Please have a look to following samples Category:Present-day Grand Est photographs taken on 2002-06-21 ("taken on" category on category level, files without "taken on", see template), Category:Fire at 111 Tonawanda Street, Buffalo, New York ("taken on" category on category level, files without "taken on") or Category:Spring Station, Lexington Road and Cannon's Lane, Louisville, Jefferson County, KY HABS (same), a lot of categories around the world made like the prior categories, search for "template: insource:/taken on/ -insource:/navbox/". Try to categorize hundreds of images at a level under "... taken on ..." in a subcategory without using Cat-A-Lot or HotCat or a batch task, just with editing the files. Have fun! --XRay talk 10:35, 1 February 2020 (UTC)
I recently categorized all the photos which I uploaded (several thousands) by country/day. In addition to the above, I found two more problem: (i) complete mess with Macedonia / Northern Macedonia; (ii) I had some photos of the Faroe Island, which is a country but not independent, it is part of the Kingdom of Denmark (but not part of Denmark in any conventional sense). I created the category tree for the Faroe Islands but added in the template the category for Denmark per day. It might be worthwhile to look at similar situations (Greenland, French Overseas Territories etc). --Ymblanter (talk) 10:33, 1 February 2020 (UTC)
Concerning Structured Commons, my understanding is that WMF is not funding it since 1 January 2020 (they funded it for two years, which are over), and the project is technically speaking closed. If any of us want to develop it further we need to do it in our volunteer time. I agree that it promised a lot (in particular, I hoped that it would replace the categories which became almost useless) but in the current state has a very limited usefulness.--Ymblanter (talk) 10:36, 1 February 2020 (UTC)
  • Another little update, so that people know what is happening:
    • {{historical photographs of country|<country name>}} has been created to make it easier to generate categories for historical photographs. I also have forgotten to say last time that I have edited all the date templates to automatically categorise all the categories as historical once the time passes. So we have 19th and 20th century, then today decades 200 and 201 (i.e. 2000s and 2010s), year 2020 is not categorised since it is current (but comes january 2021 and it will be) and then months of a year become historical as soon as they are over. I have decided to stop at the level of the month, since that is already pushing it a little, very few people will consider yesterday's photoraphs "historical". While people may argue about months, but I think that it is something that can be reasonable in many contexts.
    • There is a problem with Ireland, because the name that is used by {{country label}} is Republic of Ireland (and I tend to agree that we need to distinguish between the country and the island). But currently the whole category tree is using "Ireland", I will probably need to take some time to sit down and methodically go through the whole thing, but that will not be within a couple of weeks (I will have a trip coming up and have some things that I need to do before then).
    • I have been actively going through categories which are needed but do not exist, having written a script that helps me to search out such categories. So far I am up to the letter N. And it does take a long time to check everything and then create all of this stuff. When I am finding deleted categories, I request their undeletion rather than recreating them from scratch, I find that it is a better approach, since I am very pedantic about preserving the whole history, and if recreated, then we lose the original creation pattern. I know that it may be silly, and if somebody recreates deleted categories, I am not complaining.
    • @Crazy1880: has contacted me on my talk page about helping out with linkage of the tree to Wikidata (please do not start trolling about it). I tend to agree that this needs to be done, but I have a couple of issues, which hopefully we can figure out:
      • Currently the custom at Wikidata was to mark "Date photograph in Country" entries as "Wikimedia category". This means that it will not be possible to simply write a script that generates the whole tree for dates in Wikidata and then once the category is created, it will be automatically linked to the category. The problem is that admins on Commons tend to delete the categories when they happen to be empty, even when they are categories related to date of the media, and are emptry only temporarily (hopefully). Does it make sense to have an entry for the category that is not here? If that is ok, then maybe I am overreacting.
      • @Crazy1880: has stated that they are willing to help out with automation. I am unsure if I'll be able to deal with it before my trip.
    • Overall I am quite surprised that my overhaul has not generated any negative backlash and generally some people are even helping out. ℺ Gone Postal ( ) 06:54, 7 February 2020 (UTC)
And another thing to consider is videos. Today they are categorised only into their years. I have made {{videos from country by year}} for that, in line with the current naming convention for individual countries. I will still need to edit {{taken in}} so that it detects when it is applied to a video and does everything correctly. Eventually as video uploads increase we can create a parallel category tree for videos in months and days, but I would not want to do it today. Unless there will be sufficient demand for something like that. ℺ Gone Postal ( ) 06:55, 10 February 2020 (UTC)
Also we need to consider what to do with disputed territories, or non-recognised territories (Crimea, Hong Kong, Catalonia, etc). ℺ Gone Postal ( ) 06:55, 10 February 2020 (UTC)
  • We currently organise photos into images and then images into works, we also organise videos into works. The question then becomes, should we create a category between images and works, something like visual works which represent something that you can see (as opposed to audio) or is this something that is already too much? ℺ Gone Postal ( ) 19:55, 15 February 2020 (UTC)

February 01[edit]

Excessive number of images?[edit]

As a spin-off from #Mass DR of sexuality - there are some good points made in the opening statement by User:Prosfilaes. Indeed, there are subjects (he provides the Tower Bridge as an example) where we have literally thousands of images, and many of those are of mediocre quality (but still above the threshold when one can safely nominate them for deletion for quality reasons, e.g. too blurred). Whereas one can argues that some of these mediocre quality images illustrate some aspects (some details, or views from an unusual side) which good quality pictures do not illustrate, one can still safely assume that we have several thousands of images for this topic - I do not want to call them garbage, because people took trouble to go there, take pictures, upload them on Commons etc - but which are unlikely to be useful for any illustrative purposes, and they also clog the directories, if one searches for a reasonable quality image one has to wade through a lot of images which are clearly not qualified (and yes, I know about quality image search, but often I am not looking for a quality image, but for an image illustrating some particular aspect). In relation to this, several questions:

  • (i) Do we expect that in the future we will run into problems related to hosting of these images (too much space needed, too little money, possibly too low admin to file ratio) or this concern is unreasonable;
  • (ii) What is the general community sentiment - should we leave this as it is, or should we try to delete (or discourage upload) images which are of relevant subjects but have inferior quality in the situations there are plenty of superior-quality images around;
  • (iii) I am sure the problem has been discussed before - are there any pointers? Any thoughts that the consensus might have changed or will change?

My motivation here is that I have a lot of images from my travels which are of a reasonable quality but, with a few exceptions probably not at the quality image level; they illustrate notable subjects, and I recently uploaded them a lot, but I would like to understand whether in the future they could be deleted as a result of a quality drive or smth.--Ymblanter (talk) 10:25, 1 February 2020 (UTC)

Hello, there are several things that we should keep in mind:
  1. Commons preserves all media uploaded here, unless absolutely required to delete it. So even when the file is "deleted" it is actually simply not accessible by the public. So there is very little chance of running out of disk space, which can be solved by deleting images.
  2. My approach here is to encourage uploading quality media, and to do my best to do so, rather than discouraging anything. Because, although I can relate to your point, there is a huge difference between not being able to find something due to the amount of media, and being unable to find something because it has been removed or not uploaded in the first place. The first can be resolved by spending a little time, the latter cannot.
  3. I hope that images will not be deleted just because some better quality images appear to illustrage some general topic. Photographs illustrate much more than just their subject area, they illustrate the time of the year in a specific place (when taken outside), year itself, etc. Often media can be used for educational purposes, which cannot be predicted in advance. Of course, I will not go as far as to suggest that we create Category:Photographs taken while forgetting to take a lens cap off by time of the day in January 2020, I can see how somebody may be interested in a selection of photographs based on their metadata alone, or based on their colour scheme. For me the threshhold should remain as "Is the file educationally useful?" and not "Is it more useful than other files already on our system?".
Thanks for continuing this important discussion in a calm manner. ℺ Gone Postal ( ) 11:41, 1 February 2020 (UTC)
Part of my problem with the Tower Bridge photos, is that we have hundreds of photos illustrating that the Tower Bridge was the same in 2013 as it was 2012 and 2014. There is some difference between not being able to find something due to the amount of media, and being unable to find something because it has been removed or not uploaded, but I think you exaggerate and forget about off-Commons. If I had all the time in the world, I could save up and photograph many modern subjects personally. If I'm blowing past a Wikipedia article and say "we need a photograph of this specific thing here", I may not be willing to spend more than five minutes on it. Moreover, a plethora of low-quality images may cause me to miss the best quality image.--Prosfilaes (talk) 23:23, 1 February 2020 (UTC)
We might have "hundreds of photos illustrating that the Tower Bridge was the same in 2013 as it was 2012 and 2014"; but we might also have users who want a pictue of "a blonde woman in a red dress on tower Bridge"; "a blue Ford Focus on Tower Bridge", "two taxis passing on Tower Bridge", or any other such combination. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 21:24, 7 February 2020 (UTC)
For what reason? It is certainly not in our educational scope to provide all combinations of "two x passing on Tower Bridge". It is also not free to do so; works take time to be categorized and license checked. And it's pretty pointless to search for those, because we don't have them, and won't have them. In the fantasy future, where one can cross Category:Multiple taxis with Category:Tower Bridge, and get something, I can't imagine how many hours will have gone into categorizing photos so that out of the tens or hundreds of thousands of photos of Tower Bridge we'll have, one could find the one they needed. And you know what? They won't, because so many of those hundreds of photos of the Tower Bridge are all the same, taking the same basic photo with changes to weather and slight changes to angle. If they happened to catch "two taxis passing on Tower Bridge", it's not going to be the picture of two taxis passing on Tower Bridge they had in mind; it's more likely to be one that happened to have two taxis in it.--Prosfilaes (talk) 05:56, 10 February 2020 (UTC)
See Commons:Structured data, as for "works take time to be categorized and license checked", the proposal to delete existing images will create more, not less, work. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 18:52, 14 February 2020 (UTC)
I don't see anyone advocating for deletion here, so that's strikes me as a straw man.--Prosfilaes (talk) 01:39, 15 February 2020 (UTC)
Then you need to re-read the OP, which includes (emboldening mine) "or should we try to delete (or discourage upload) images which are of relevant subjects but have inferior quality in the situations there are plenty of superior-quality images around". Shall we take your apology as read? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 11:55, 15 February 2020 (UTC)
The social issue for Commons is how we agree to go about curation. Right now the choices are:
  1. Try to get the worst files deleted
  2. Create gallery pages, even though it's unclear how useful they are
  3. Nominate images for Valued or Featured status
These are potential options, but it has always seemed obvious to me that we need to incentivise the Valued Image process. If someone were to go through 100,000 images within a specific topic area or batch upload project, and pick out the top 1000 that are the best from that collection, that's super work that should be rewarded.
How about creating different levels of barnstars for curation (like senior/master/wizard curators?), or start some competitions with some merchandizing thrown at it?
How about creating some use cases for better tools to see VI/FI when using gallery and slideshow tools for categories? If using VI could be a realistic substitute for creating gallery pages, folks might be at least as engaged with that work as they are with deletion requests. -- (talk) 11:58, 1 February 2020 (UTC)
To be honest, after Commons:Featured picture candidates/File:Tom Thomson - The West Wind - Google Art Project.jpg I decided that I will never nominate anything for quality images or vote for any, because the process is hopelessly broken. People did nominate my images and some got some status, but I did not assist this in any way (except obviously for uploading them in the first place).--Ymblanter (talk) 12:20, 1 February 2020 (UTC)
Concerning curation, would you please explain what you mean by curation?--Ymblanter (talk) 12:20, 1 February 2020 (UTC)
Just the dictionary definition: the action or process of selecting, organizing, and looking after the items in a collection...
Marking the best images so users can easily find them, is one method for us, the other being galleries. Maybe we can come up with easier and smarter workflows, for example the automation of gallery creation using FI/VI status would be a relatively trivial bot job. -- (talk) 12:51, 1 February 2020 (UTC)
  • I do agree that curation is the largest challenge, and while I was not an early fan of structured data, once I gathered enough caffeine to sit through a few talks on the possibilities...well, the possibilities are promising. There is still an infrastructure problem, and it's not clear that it will be terribly useful in the next two or three years, but once the infrastructure is in place, it should make things a great deal more navigable.
As to sheer number of images, I think a lot of the misunderstanding there, especially from non-Commons users from other projects, is that they've just never really spent a lot of time with traditional archives. If anyone thinks the Library of Congress doesn't have a substantial number of...I dunno...unidentified photos of miscellaneous spoons, then that's a problem with their personal perspective, not with us or with LOC. In that respect, Commons doesn't look all that different once you get the lay of the land of what an archive looks like. GMGtalk 12:34, 1 February 2020 (UTC)
But the Library of Congress sucks for our purposes. As a traditional library, I have a more complete collection of (the US published) w:GURPS, and what I have is better cataloged, because it is not something that the Library of Congress cares about, so what they do have is tossed in a box and cataloged in a half-assed manner. If I want to find pictures of miscellaneous spoons, I wouldn't go to the Library of Congress, for the same reason; there are people out there who care much more about spoons and categorizing them. Those LoC collections are useless; unless you live in DC and your time isn't worth much, you should go elsewhere. In those case, the LoC collections are not standards to look up to.--Prosfilaes (talk) 23:23, 1 February 2020 (UTC)
  • (i) "too much space" won't be an issue. To the degree that's an issue, it has been an issue for years, in the sense that a complete backup of Commons by a third party isn't too realistic. But for Wikimedia? No. No problem, quite simple, though it's a bit complicated to explain. The majority of files on Commons are images, and here we are specifically talking about photos. Photos basically come in two formats: JPEG (1992) and HEIC. (2013) Every other format is so little used it's irrelevant and everything between 1992 and 2013 basically failed for photos. (I'm oversimplifying stuff okay) The patents for HEIC aren't going to expire for well over a decade from now, so #care on that front.
I said all that for only one reason: to say compression isn't a factor and won't be for the upcoming decade. Well, unless AVIF takes off as a native format for cameras, but that's speculation. Something that isn't quite speculation is that megapixels go up. We get more of them, not less. And flash-based storage, which cameras use nowadays, also goes up, so compression ratios don't need to go up. So photos get bigger.
With me so far?
Now skip 10 years into the future. Those old pictures we have are now suddenly tiny compared to what people will be uploading in 10 years. There will be no point in removing any of them. If you are running out of space, what are going to delete first: Video CDs (up to 1.6GB for a movie on two discs), DVDs (typically 6-8GB for a movie), Blu-rays (typically 35-45GB for a movie) or Ultra HD Blu-rays (typically 60-70GB for a movie)[1]? Yeah, you're not gonna bother sorting out your VCDs are you? And I'm actually ignoring the fact here that the WMF doesn't delete anything, because everything (apart from some stuff that's too illegal) can be undeleted.
Too little money? Money equals disk space, same argument.
Too little admin to file ratio? That's not a thing. File count ≠ admin workload. And while there are exceptions for sure, older images have typically already been checked. The majority of admin workload is (I think) directed at new uploads. A shortage of admins is pretty much an ongoing problem, but the people of the future aren't too likely to thank us people of the past for deleting a bunch of images. Also, the actual deletion and sorting out would be a massive undertaking if one wanted to delete a number of images that would have any impact at all. An undertaking so massive we don't have the manpower to do it, not just in terms of admins but also volunteers.
  • (ii) deletion is out of the question basically. Better categorization, making VI/FPC so it's less broken, those are much more sensible solutions. Discouraging new uploads, well.. if you can do that without also discouraging users from uploading the images we do want, sure, but I wouldn't know how.
  • (iii) I can't think of any particular discussion right now, but I think I've seen the subject before. And I don't think it ever goes anywhere.
There's also more to photos than meets the eye. Some photo may be of lower quality, but could have a less restrictive license. If I'm creating a derivative work, I'll sometimes avoid CC BY-SA because BY-SA will "upgrade" a collage of 50 public domain images to BY-SA. Similarly, some people will avoid images that have fallen into the public domain in the US but not in Germany or vice versa. And personally I'll also avoid images where the history isn't quite as clear as some alternative with lower quality. Flickr account with one upload and no EXIF or a slightly more blurry photo from an established photographer? I'll take the latter, thanks, and I'll be mortified if that's the one you deleted because its quality was lower! - Alexis Jazz ping plz 14:34, 1 February 2020 (UTC)
I think we should keep nearly every free licensed image and also say that we want to have many files. But we also should think about methods of curating images that is makes is easier for endusers to find what they want. But for third party services we should serve as many as we can. --GPSLeo (talk) 17:22, 1 February 2020 (UTC)
I don't know what we should do. I'm a bit frustrated that Category:Varnum Building has two images of a historical building in a US town with a hundred thousand people, in a location that maybe five thousand people crossed a day (traffic jams on that street were epic), and they're both after the fire that destroyed it. People often don't see where a photograph would fill our holes, and sometimes it is too late. As GPSLeo implies, discouraging people from uploading photos of the Tower Bridge is not really going to get us photos of interesting, but less heavily photographed, places. Maybe VI/FPC could be better, but I've got the feeling that there's more interest there in pretty pictures than in photos that are useful to Commons.--Prosfilaes (talk) 23:23, 1 February 2020 (UTC)
Well, I do not know. In the town where I live there are several thousands of listed historic buildings, and most of them have zero photographs on Commons. I am using my time on the weekends (when there is good weather, which does not happen too often) to take pictures of those and upload them on Commons. (I see that there is another photographer doing the same, so probably we will have all of them covered in a couple of years). I have a lot of travel photos of places which have encyclopedic notability, or are generally useful, and I upload these, several per day (I even have recently written an essay about this, [2], which is however trivial for Commons regulars). I do not think I am in any way special, may be people just do not realize what the best practices are.--Ymblanter (talk) 23:42, 1 February 2020 (UTC)
This may be why some Wikimedia chapters decide not to participate in Wiki Loves Monuments. Wikimedia Czech Republic shifted its focus to lesser-known monuments in a currently running "Describe a monument" competition which awards wrting new articles. With ~2 weeks left 77 new articles were submitted so far (since January 15). The overlap with Commons may be limited, however. I am not sure how many editors decide to take their own photos. Pinging @Aktron, who may have something to add on this topic.--TFerenczy (talk) 10:59, 2 February 2020 (UTC)
HI! The contest does not focus on Commons. The reason we are doing this with WMCZ is clear: 3 years brought us 25k images of cultural monuments, 25k were probably taken by volunteers in the years after (past 2014). So we have 50k of files of cultual monuments (40k of items are listed by National Heritage Institute) but only a small amount have their own articles. This star difference goes against the logic of our project and that is why we want to balace it. Aktron (talk) 11:04, 2 February 2020 (UTC)

Curation idea[edit]

@Prosfilaes, GreenMeansGo, Ymblanter, : I've been thinking about new ways to curate files, it hadn't fully taken shape but I just now took the time to write down what my idea roughly is. But maybe you could also share your thoughts on this. I think VI/FPC are not really useful to solve the perceived problem. I would suggest a new "seal of approval" (or completely overhaul VI) where any patroller (possibly even autopatroller) can give a file a "seal of approval". The requirements for that would be something like: its copyright status is beyond reasonable doubt. That would mean a photo from a Commons or Flickr user with only 1 upload and no OTRS won't be eligible. We don't delete such files because AGF, but we have little to go on in such cases. If there's anything else that makes a file suspect, it equally won't be eligible, the threshold for that will be lower than the threshold for starting a DR. In addition it should be among the best files of its kind, which is a bit more loose than the Commons:Valued image criteria. If we have 50 images of the Tower Bridge in the same weather conditions, same time of day, nearly the same angle, there'll be no problem giving 3 or 4 of those the "seal of approval", especially if they have different licenses. Also, photos from different angles can all be given the seal, whereas VI will typically force you to pick one. So Commons:Valued image criteria 1 and 2 are loosened, 3, 4 and 6 would be the same. 5 I would say would be optional, but if missing the file should be categorized into a "location wanted" category or something.

So to sum up: like VI, but any (auto?)patroller would be allowed to tag files without voting. (topic ban for anyone who abuses this or continues to tag files despite getting opposed frequently) Commons:Valued image criteria 1 and 2 are loosened and 5 would be optional. A copyvio check is included (which VI lacks) that found the file to be most likely properly licensed. The exclusions (presentations, audio, video, etc) also won't apply. - Alexis Jazz ping plz 09:08, 3 February 2020 (UTC)

Well, thinking on terms of getting something for nothing, I think it would be useful to have some metric of a "use factor" built into the "good pictures" drop down menu on categories. There is at some level never going to be any substitute for humans browsing images and selecting which ones are best, but we already have a system in place which does this naturally, specifically, humans from all our sister projects deciding what images to use in their work. Obviously that's not helpful for small categories, but if we look at something like Category:Washington Monument, we have a category with over a thousand images, that has entries on 59 projects, presumably all of which actually use media from this category. So if someone makes a new entry, and sits down to create our missing Wikivoyage page, probably one of the best indicators of what media they might want to use is what images others have already selected to use themselves. GMGtalk 12:00, 3 February 2020 (UTC)
@GreenMeansGo: very good point, I was going to mention it (though not so thoroughly) but I forgot. (long rant about QI/VI removed - I realized how unlikely it is to change anytime soon after Rodhullandemu's comment, so let's not waste time) - Alexis Jazz ping plz 22:03, 3 February 2020 (UTC)
Sorry, if I'm going to walk for miles round the northwest of England in all weathers taking photographs that are better than the ones we have, particularly the Geograph crap, a little recognition warms my heart, improves the quality of my photography and in the absence of financial reward, is all I've got. Any change to VI or QI and I'm out of here. Rodhullandemu (talk) 22:10, 3 February 2020 (UTC)
@Rodhullandemu: hmmmm, point taken, but that doesn't make VI useful for finding useful media. I guess this is one of those things that'll never really change. You'd still be able to move the "new VI" from that lowres Geograph image to your own photo and apply for QI, but if that isn't enough, I guess we'll have to stick with what we have. - Alexis Jazz ping plz 22:16, 3 February 2020 (UTC)
@Alexis Jazz: VI and Qi aren't about finding images. Rodhullandemu (talk) 00:12, 4 February 2020 (UTC)
@Rodhullandemu: so you won't mind if we remove VI and QI from Help:FastCCI? Because that's the main gripe here I think. FastCCI presents VI and QI as a way of finding good images, and that doesn't work at all. - Alexis Jazz ping plz 10:40, 4 February 2020 (UTC)
Concerning the usage, I noticed that many articles, especially on the smaller projects, use the same photo which either one of the bigger projects already uses, or use the photo which is on Wikidata (and often these two are the same). People rarely go to Commons to search for better images.--Ymblanter (talk) 09:41, 4 February 2020 (UTC)
For my own part, I often do. But it seems this is a question best answered with data. GMGtalk 11:38, 4 February 2020 (UTC)
Many articles are created by translating an existing (mostly the english (6mill articles!)) article. With the content translation tool the images are taken to the translated article without a choice of other images. Translating without the tool will often have the same result. --C.Suthorn (talk) 02:43, 8 February 2020 (UTC)
Now, concerning the general suggestion, if I get it right, it is to create a new layer of images between QI and nothing, similarly to how many Wikipedias have recommended articles, a layer below GA. It might work, though I see some immediate issues (and there are probably way more, but we are discussing it at the level of an idea):
Indeed, there must be no doubts about the license status of an image (including freedom of panorama, a concept even many experienced users have problems with) and the scope;
The suggestion to assign the status without any discussion, by a select group of users seems reasonable. It should be also some procedure to demote such an image, and I guess the discussion would not be needed either;
My main problem is that users have vastly different standards as far as quality is concerned. Some would say that chromatic aberrations at the periphery make an image such garbage that we should be ashamed showing it; others would not mind having geometric distortions or even blurring. This can cause warring for assigning the status, and generally must be somehow regulated, but I am not sure what would be the best way to do it.--Ymblanter (talk) 11:29, 4 February 2020 (UTC)
  • Don't worry about deletion to save the Wikimedia Foundation from using space, because we do not delete images. We just no longer display them. 22:39, 3 February 2020 (UTC)
  • I also really want a new way for curating images. I think the most important thing is that this dose not work with wikitext templates, becaus they can not be used in the standard search. Maybe we make three different types: preferred, discouraged and unassessed. This information should then be stored in the page metadata. --GPSLeo (talk) 14:51, 4 February 2020 (UTC)
  • If this is of interest to a significant number of people, should we create Commons:Curation and continue discussing there?--Ymblanter (talk) 09:33, 9 February 2020 (UTC)
@Ymblanter: I'll just create it anyway, see where we might go from there. - Alexis Jazz ping plz 15:29, 10 February 2020 (UTC)
@Prosfilaes, GreenMeansGo, Rodhullandemu, C.Suthorn, GPSLeo:  Done: Commons:Curation, feel free to add/improve stuff. Probably discuss on the talk page so we can hash out the idea on the project page. - Alexis Jazz ping plz 16:04, 10 February 2020 (UTC)

February 11[edit]

DATA namespace and COM:SCOPE[edit]

I have only just discovered that Commons has a DATA namespace for storing structured data. Since structured data is not a media file, I can't figure out how this squares with COM:SCOPE, but I am sure it must have been discussed before. I haven't been able to find one (but that might be because the phrase "structured data" is used to refer to Wikidata quite a bit. Can someone point me to previous discussions or explain how structured data is within Commons scope? Thanks. World's Lamest Critic (talk) 04:25, 11 February 2020 (UTC)

Just for understanding: Did you find Commons:Data with its several links? Note that the term „structured data” is in some kind ambiguous and is usually not used for the data in Data: namespace. Regarding project scope: It would probably belong into an own section or subpage, the .map and .tab have to be JSON files, though. But, yes, apparently this is missing. — Speravir – 18:23, 11 February 2020 (UTC)
Yes, I found Commons:Data. It was no help at all. Whether or not this lives on a subpage, it is still not covered by COM:SCOPE]]. World's Lamest Critic (talk) 21:53, 11 February 2020 (UTC)
Just for the remark: In my “with its several links” lies the clue. — Speravir – 01:10, 12 February 2020 (UTC)
@Speravir: I think I followed every link about the DATA namespace on that page. If you think one of the links answers my question about how this aligns with COM:SCOPE, please just tell me where to look. World's Lamest Critic (talk) 03:40, 12 February 2020 (UTC)
Really not that important anymore: The link Keegan gave you can be found from there … My (apparently wrong) expectation was if you was on COM:Data you already would have found this yourself and would have asked for more information. — Speravir – 17:29, 12 February 2020 (UTC)
@World's Lamest Critic: here's the discussion about the Data: namespace on Commons. There's information on usage on the help page on mediawiki.org. Keegan (WMF) (talk) 18:41, 11 February 2020 (UTC)
@Keegan (WMF): Thanks. I see several people opposed this namespace here because it was out of scope for Commons. Strictly counting votes, 28 users supported this and 10 users opposed it. So out of all the users on Commons, 38 of them expressed an opinion. I don't understand how this namespace got added with such little discussion, especially when the scope issue is unresolved. Can you explain? World's Lamest Critic (talk) 21:53, 11 February 2020 (UTC)
@World's Lamest Critic: It seems that Yurik considered that discussion as adequate endorsement and implemented it. Perhaps he could comment further. You're correct that the scope issue has never been resolved, however. I suppose at this point it's a moot issue and we should just add the Data namespace to COM:SCOPE. Alternately, you could propose removing the Data namespace from Commons under the argument that it doesn't conform to COM:SCOPE, but I don't imagine that such a proposal would achieve any level of consensus. Kaldari (talk) 16:01, 12 February 2020 (UTC)
Why would this be a "moot issue"? When it was discussed, users pointed out that it did not belong on Commons because it was outside the scope of Commons. I don't know how @Yurik: could ignore that, but it's not too late to put it somewhere else, since it seems to have been pretty much ignored until just now. You work for the WMF, don't you? What's your role there? World's Lamest Critic (talk) 21:04, 12 February 2020 (UTC)
@World's Lamest Critic: I just meant it's a moot issue because the Data namespace seems to have become more or less accepted. I don't personally have any opinion about that and you're welcome to start nominating those pages for deletion if you like, but I imagine it would be hard to build consensus to delete them. Regardless, I agree with you that our scope guidelines need to match what we actually host. FYI, Yurik used to work for the WMF several years ago, but doesn't currently. Kaldari (talk) 05:50, 16 February 2020 (UTC)
@Kaldari: Sorry. I meant you work for the WMF, don't you? What is your role? World's Lamest Critic (talk) 23:24, 18 February 2020 (UTC)
Yes, I'm a director of engineering. I didn't have anything to do with the Data namespace though. Around here I'm mostly just a volunteer admin (which predates my employment at the WMF). Kaldari (talk) 04:56, 19 February 2020 (UTC)
@Kaldari: Sorry, I shouldn't have assumed you were watching the discussion. Just pinging you for a response. World's Lamest Critic (talk) 04:49, 16 February 2020 (UTC)
I have no opinion or idea of the history; I had the links handy in a tab as I was just talking to someone about the Data namespace the other day and you asked to be pointed to a previous discussion Keegan (WMF) (talk) 17:05, 12 February 2020 (UTC)
BTW: Only some threads away in #Our World In Data pointed to some other issues. The missing ability to categorise the datasets is IMHO a quite huge one (and do not let us think about adding ability for structured data like for media files). — Speravir – 17:39, 12 February 2020 (UTC)

Misplaced invitation to "tag" images[edit]

Screenshot

Much as I am in favour of structured data in Commons, I was dismayed to see this notice displayed after I uploaded an image just now:

"Help make images more findable for everyone

Commons has a new tool that will suggest tags for images you upload if you haven't already added tags. When you confirm accurate tags, you're helping make images easier for everyone to search for.

[...]

Ready to start tagging right away? Give the tool a try by tagging popular images now!"

These so-called tags are intended to be added as "depicts" statements.

There is a big difference between a "tag" and what should be a value in a depicts statement. For example, I might "tag" an image of an autumnal tree with "autumn" and "gold"; but that is not what the image depicts. I might "tag" a picture of a specimen of Quercus robur with "tree", but I would use the more precise Quercus robur (Q165145) for a depicts value.

Adding "tags" in this way will pollute the supposedly structured data with generic keywords.

Furthermore, the tool for adding them has other equally serious, flaws, as I commented recently when I gave feedback on it - in my view it is not yet fit for general release.

I've seen no community discussion of whether a notice such as the above should be displayed, much less consensus for it, and equally no consensus to use the "depicts" statement to hold keywords or tags. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 15:10, 11 February 2020 (UTC)

 Support Yeah, what he said. It would also benefit from a "Don't show me this again" option. Rodhullandemu (talk) 15:16, 11 February 2020 (UTC)
 Support similarly. I already find more bad depicts statements than good, this will only exacerbate that. - Jmabel ! talk 17:10, 11 February 2020 (UTC)
 Support Yes, it's annoying right now. We need to be able to add tags or reject wrong ones. T8612 (talk) 18:39, 11 February 2020 (UTC)
 Support, out of principle. The whole thing is a pie in the sky. -- Tuválkin 01:17, 12 February 2020 (UTC)
 Support I agree with Andy that we first need a way to not just ignore or skip bad tags, but expressly mark them as "inapplicable" or "rejected", and actually (before reading his comment on the topic) posted some remarks to that effect. Gestumblindi (talk) 21:11, 12 February 2020 (UTC)
 Comment The above comment is not crafted as an RFC-type consultation, so it's not clear what support and oppose even mean in this context. To provide a slight counterpoint: even though the system as implemented now is not perfect (nothing is), let's not rule out controlled exploratory features altogether. What should be done is to refine the scope, parameters and instructions so that if machine learning is indeed being used for image classification, it is done in a logical and useful way and not just wildly guessing at visual themes in a random image. As one of the few folks who has experience implementing the addition of depiction statements at scale using ML (7,000+) via the Wikidata Game outreach:GLAM/Newsletter/February_2019/Contents/USA_report, I can say that there are constructive ways to do this that can work. My project was helped by the fact we focused on 2D reprsentational artworks and specifically, paintings. The implementors of the SDC tagging feature may do better by gathering some more context about the nature of the uploaded image before applying generic ML techniques. -- Fuzheado (talk) 03:23, 14 February 2020 (UTC)
  •  Comment "Tag" is the wrong word here, but I'm not sure if it's just an English issue, or if this is a multilingual issue? Can native speakers have a look at the translations to see if they are better? Thanks. Mike Peel (talk) 15:00, 14 February 2020 (UTC)

Since there are apparently no plans to fix these issues in the near future, how do we get this turned off until they are resolved? Maybe Keegan (WMF) can advise? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 13:26, 14 February 2020 (UTC)

Thanks for the useful feedback you provided on the computer aided tagging talk page. We are still working on the tool and fixing bugs, but many people who have opted in to depicts suggestions find it useful, so we do not plan on turning it off completely at this time.
We do hope to add the ability for users to add their own custom tags in an upcoming release. Also, there's an existing ability to blacklist certain inappropriate/inaccurate concepts that come from the Vision API. We have already added some things to that blacklist ourselves, but we're also exploring a feature that will expose the ability for community admins to edit and add to the existing blacklist.
Relevant existing tickets:
Tag blacklist: [3]
Suggestions that contain depicts values already on the image: [4]
Landmark detection: [5] RIsler (WMF) (talk) 21:56, 14 February 2020 (UTC)
@RIsler (WMF): "many people who have opted in ... find it useful" That's not the issue; the issue is the quality of the data the tools is leading them to generate; and the nuisance that the tools nagging is causing to others. and the point that "There is a big difference between a 'tag' and what should be a value in a depicts statement", none of which, I note, do you address. I didn't suggest "turning [the tool] off completely", I want to know how to turn off the nagging notice described in my post above. The decision as to whether the notice - or indeed the whole tool - is enabled is surely the community's to make? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 22:18, 14 February 2020 (UTC)
If you simply want to "turn off the nagging notice," you can click the X that you see in the top right corner of your screenshot and the notice should disappear forever. Have you tried that? If it does not disappear, then that's a bug. Keegan (WMF) (talk) 22:37, 14 February 2020 (UTC)
@RIsler (WMF): It is indeed buggy, as it reappears after every upload, even after that "X" has been clicked, which I did on first seeing it, and several times since. But I want to know how to turn it off for everyone, and especially the inexperienced contributors, for whom it is particularly misleading. I note that you still do not address my substantive points, which I repeated for clarity in my last post. To be even more clear: the tool (whose aims I very much support in principle) is no better than an "alpha" release, and should not be exposed to users, other than those familiar with both the community's intended use of depicts statements and the need to robustly test its fitness for deployment. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 23:01, 14 February 2020 (UTC)
I've created a bug report and we'll take up the specific issue of the X (ticket here). As for your other points, we agree that the tool can be improved, and the dev team have specific tasks that are underway to achieve just that. RIsler (WMF) (talk) 23:24, 14 February 2020 (UTC)
So you're not going to address them, and you're not going to say how we can have this benighted invitation notice removed for all users. The team have - on the available evidence - no specific task underway to achieve anything to do with the big difference between a 'tag' and what should be a value in a depicts statement, and no specific task underway to demonstrate consensus to use the "depicts" statement to hold keywords or tags. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 23:56, 14 February 2020 (UTC)

┌─────────────────────────────────┘
The issue is not how to improve it. The elephant in the room is that it completely destroys the structured approach to finding images that has developed, albeit somewhat haphazardly over the years. Search for a keyword, and if an image has that tag, it will show up in thousands of result. That's unhelpful to the point of being useless, if not actually hostile. Do it the way we do now and you are much more likely to get cogent results. It's not helped by people misunderstanding how categories should work structurally, i.e don't categorise things by their parts, which invokes COM:OVERCAT. TBH, I'm getting somewhat fed up of other projects coming here and saying "We do this, so will you", without any understandng or even consultation. No project is master. If WMF really wanted to be useful it should spend some time considering whether my block on en:WP withstands serious scrutiny, considering its inconsistency and breach of its own policy. As a former lawyer myself, I'm used to hearing lawyers laugh. Good evening. RHE out. Rodhullandemu (talk) 00:01, 15 February 2020 (UTC)

  •  Comment The conflation of 'tagging' with the notion of 'depects', in the tool UI and in RIsler (WMF)'s response, above; and RIsler (WMF)'s unwillingness to discuss the difference between the two despite several clear invitations to do so, both are deeply worrying and indicative of a don't care / fait accompli attitude. The absence of a common frame of reference for commons depicts structured data is clearly a red flag. This has the feeling of a product-push initiative in which a tool designed to 'solve' a poorly analysed problem situation now has sufficient momentum to ensure it'll be its own train wreck, albeit one with great metrics. Wiser heads would take the hint and return to the first principle of deciding how depicts structured data should work on commons, in terms of scope, granularity and ontology, before offering an ACME tool. --Tagishsimon (talk) 02:28, 15 February 2020 (UTC)
Suggestions case-study #1
depicts: people -- photograph -- child -- standing -- snapshot -- black-and-white -- monochrome -- monochrome -- photography ? Suggestions case-study #2
depicts: natural landscape -- nature -- bank -- water -- properties of water -- tree -- river -- natural environment -- leaf -- wilderness -- sky ?
  •  Support. Yes. Hit the brakes. *Now*. It's time to pause so the community can assess and review and analyse what has been produced in this initial trial phase, and also come to views as to how we want "depicts" to be used. It's time now to take stock and assess, *not* to ramp it up and push on blindly.
Don't get me wrong. I think the experiment is very interesting, and I do think the output is producing is interesting, and has the potential to have real value.
But just click on Special:SuggestedTags#popular and look at the kind of tags that are being suggested. For example, the tags for (on the right) the first two images I was offered:
people -- photograph -- child -- standing -- snapshot -- black-and-white -- monochrome -- monochrome -- photography
natural landscape -- nature -- bank -- water -- properties of water -- tree -- river -- natural environment -- leaf -- wilderness -- sky
These are, I think, very very interesting. But they are very very different from the way depicts (P180) has been used so far. Given how plainly revealed that now is, it is appropriate to stop, review, discuss, and determine what it is we actually want.
Until now, inheriting practice from Wikidata, the aim for depicts (P180) has been to be very specific, very accurate, very concrete, very low noise. To identify as precisely as we can exactly what is in the picture.
The tags are not like that. They are far more general, far more impressionistic, quite likely to reflect mood or technique or atmosphere or style rather than specific concrete content elements.
Personally as I have said, I think that is quite interesting, and does have potential value. But I think Andy hits the nail on the head that this is something very different from the curated approach depicts (P180) has so far represented; and if it continues further to any degree it seems likely to rapidly destroy very much of the work that's been done so far trying to add careful depicts (P180) statements to allow precise and specific retrieval, by swamping the property in a vast amount of genericity and noise.
Another part of the problem is we are flying blind. Without a functioning SPARQL query system, we simply don't know what the tool has been doing. We don't know how many tags have been added specifically by this tool in total; we don't know which individual tags have been added and how often; we don't know in aggregate what sort of tags have been added and how often; we can't compare what the tool has done with what existing categories there may be on images; and we can't compare what tags have been added via the tool to what depicts statements there might already have been on the image by other routes.
We desperately need to be able to generate this kind of overview information, if we're to make sensible assessments. And we need to be able to robustly identify which tags have been added via this tool route -- they ought at the very least to have a wikibase reference to say this is where they have come from, so that when we do have a SPARQL system, we can identify them.
It also worries me that the community seems to have no 'emergency stop' button. If a bot runs out of control, the admin corps can block it. But if the tool is causing damage, there seems to be no way the community can stop it. That is something I think that does need to be addressed. The community must have a 'stop' button.
Ultimately, I think Andy has exactly identified the issue, that these tags are qualitatively different from depicts statements, and it is damaging to the what people expect from depicts statements, if they go on being added pell-mell.
I think the community needs to have a serious think about this -- and we need the data, to inform that thinking. But until we can do that, the immediate step *now* should be to stop adding any more depicts (P180) statements.
One possible way forward, that could be rapidly implemented, might be to create a new, different property that the tool could add -- perhaps "tag", or "keyword", or whatever. What it's called doesn't really matter, but doing so would allow the tool to continue to be being used, and to be generating data, without contaminating the specific established meaning and expectations of depicts (P180). Jheald (talk) 23:51, 15 February 2020 (UTC)

Why this matters[edit]

Anyone wondering why there is concern can see the kind of "tags" being added in this search.

Here are just a few examples:

This is not structured data; it is unstructured noise. I don't have the resource to revert the number of bad statements I found - and all this was in one set of 250 edits.

I did, though, revert the tram example. Troublingly, although I reverted six "computer aided tagging" actions only one shows up in the page history as being "computer aided tagging reverted", so the stats will show a 5:1 ratio of good:bad edits, and cannot be trusted. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 00:52, 15 February 2020 (UTC)

Looks perfectly good to me, exactly as keywords should work. Replacing "tram" with "Vario LF electric tram" would just make it as useless as existing Category system is. --- [Tycho] talk 01:26, 15 February 2020 (UTC)
How is Category:Trams useless? Catscan isn't working for me, so I don't know how many files are in the category, but it's clear there's at least a thousand. How is returning a thousand results for keyword:tram going to help anyone?--Prosfilaes (talk) 09:04, 15 February 2020 (UTC)
You are absolutely right that this is "exactly as keywords should work". But the structured data property into which these loosely-applied keywords are being shoehorned is not "keyword" or "tag"; it is depicts (P180), which has an entirely different purpose. Where was it decided, by community consensus, that we wanted to apply a plethora of redundant keywords to images, and where is the consensus to abuse P180 to do so? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 11:05, 15 February 2020 (UTC)
If all 10k tram pictures get "depicts tram" then automatically the Wikidata tram item gets 10k "depicted by" statements, right? That will soon create technical problems and, thus, should be prevented on technical grounds alone, before even discussing how not to edit a knowledge base. --SCIdude (talk) 16:17, 15 February 2020 (UTC)
  •  Info Because of this discussion and the other problems I created a proposal to restrict these beta tool to autopatrolled users. --GPSLeo (talk) 09:43, 16 February 2020 (UTC)
    Brilliant, and for one dark hour in 2019, when I felt forced to log in for the so far first + last time since May 2016, how about limiting it to anything better than "patrol", e.g., "file mover" or "licence reviewer"? –84.46.52.151 07:24, 20 February 2020 (UTC)

Our World In Data[edit]

Category:Our World In Data

Good news everyone,

we have been uploading all the available charts from [ourworldindata.org] in SVG format. These maps and charts are deliberately released to help a better public understanding of publicly available statistics about world issues including health, population and poverty.

Where possible the underpinning data has been uploaded in Commons Data namespace as tables, there are currently 380 of them. Refer to the project page. All charts are listed at Category:Our World In Data.

  • Selected example charts
  • Deaths from air pollution

  • Sulphur dioxide emissions by region

  • Tobacco production

  • Population growth against age

  • Alcohol consumption by type in Italy

If the transparent hatched background of the chart is diverting, remember to click on the image on the Commons image page to show it with a white blank background. As standard, the images are shown with different size options for PNG versions, and you may find those more usable. You can edit the SVG file directly using a text editor if you download it first. Refer to Help:SVG for suggestions about tools and other options.

Example datasets

The charts are likely to be helpful in illustrating Wikipedia articles, and volunteers may want to try creating new charts and new maps based on the datasets uploaded, for example by creating versions of maps with country names changed to more "mappable" country codes. Thanks to Doc James for the initial suggestion for this project and several others joining by email to get this underway.

One unintended consequence has been to test out the usability of the Commons Data namespace, some of the bugs and issues are on the project page, in addition to the common frustration of being unable to categorise datasets and their highly restricted JSON format. Users playing around with the datasets may have further suggestions on how to make the data namespace more usable. -- (talk) 17:18, 11 February 2020 (UTC)

User:Fæ many thanks for the first steps on this. Per here there should be 3,308 charts [ourworldindata.org] (we currently have 955 .svgs) I guess the question is what happened to the rest of them? Will look into this. Doc James (talk · contribs · email) 19:25, 11 February 2020 (UTC)
The SVGs are still uploading, one every 12 seconds at the moment!
I see a few being skipped as the way filenames are generated based on titles is not smart enough to handle variations, but it looks like a rare naming conflict which can be worked on for a later run.
Update as my unreliable broadband dropped out last night, added some code to handle duplicate titles and restarted the run this morning. There's over 2,000 SVGs and the remaining 1,000 or so to come.
Dataset upload improved to handle null numbers, so that total has increased to 514 files. -- (talk) 10:56, 12 February 2020 (UTC)
@Doc James: checking [ourworldindata.org] shows that there are lots of duplicated links, probably because the page is divided in to topics and a chart may be relevant to more than one topic. Consequently, there are 2,701 links to unique charts rather than over 3,000. -- (talk) 12:00, 12 February 2020 (UTC)
Amazing :-) Doc James (talk · contribs · email) 16:48, 12 February 2020 (UTC)
 Done 2,698 of a possible 2,071 files uploaded.
The missing charts seem to be those with the words "with autism" in the titles, which unfortunately is blacklisted; e.g. File:Share of the population with autism, OWID.svg. These missing files are probably best uploaded manually rather than spending time trying to adapt the batch upload. -- (talk) 18:32, 12 February 2020 (UTC)

The charts will definitely be useful, but as I asked above, how is tabular data a "media file" as required by COM:SCOPE? World's Lamest Critic (talk) 03:44, 12 February 2020 (UTC)

We are working to add a better data visualizer. Not sure how the data tab ended up being added here.
We have an example of the data being used here[6] Doc James (talk · contribs · email) 16:48, 12 February 2020 (UTC)

@: Just FYI, for "Description must be under a certain string length, arbitrarily this has been cut off at 241 characters in the absence of a specification" - Code seems to indicate the limit is 400 unicode code points (Why that limit is there, I have no idea. Seems super arbitrary and rather short for a description field). Bawolff (talk) 11:05, 18 February 2020 (UTC)

Thanks. Could someone add that to the MediaWiki summary where future projects can find it? Debugging this upload was made twice as long due to the amount of trial and error involved, bumping into constraints that were not explained anywhere, nor are they based on any external standard for JSON. -- (talk) 11:13, 18 February 2020 (UTC)
@:This already seems to be in the official docs at mw:Help:Tabular_Data#Restrictions_and_gotchas. Was there some other docs somewhere you were looking at? Bawolff (talk) 08:52, 19 February 2020 (UTC)

February 12[edit]

Copyright tags e.g. for Gambia[edit]

I find the Commons "copyright tags" by country extremely useful. So thanks to all involved. I recently went to check on the tags for Gambia and was flummoxed because there were none. I did a search and found a document that covers copyright law dated 2004 and decided it was time I created a tag as I had found all the other tags useful. I see there is a clever system for gathering these tags together which I don't understand. So... is there anyone here who could cast an eye over this draft and tell me if it could be published and what is the right way to do it ... or should I be bold and JFDI? Thanks for listening. Victuallers (talk) 11:40, 12 February 2020 (UTC)

Comments here are good, so best not skip it. @Kaldari: you may be able to advise considering the recent experience with FAL. -- (talk) 11:57, 12 February 2020 (UTC)
@Victuallers: It looks good to me. I say publish it! Kaldari (talk) 15:40, 12 February 2020 (UTC)
@Kaldari: Thanks (and Fae). I did as you suggested only to find that there IS a tag for Gambia already (%^^%!).... but it doesnt appear in the lists of by country tags. I have clumsily tried to change the template so it does but not sure if this will work as I don't understand the process. Thanks again for the support. Victuallers (talk) 16:15, 12 February 2020 (UTC)
@Victuallers: I fixed it up so that it should transclude into Commons:Copyright_tags/Country-specific_tags. The only step that is still needed is that my changes at Commons:Copyright rules by territory/Gambia need to be marked for translation (otherwise the fancy transclusion doesn't work correctly). Can you help with that, Jarekt? Kaldari (talk) 17:25, 12 February 2020 (UTC)
It looks like some beat me to it. --Jarekt (talk) 03:23, 14 February 2020 (UTC)

Is plantillustrations.org a source of Public Domain images[edit]

I have used countless images from the above source for illustrating articles. User:Pigsonthewing is questioning the validity of the site's claim that it hosts only Public Domain material. Could I have a ruling on this please. cheers Paul venter (talk) 14:58, 12 February 2020 (UTC)

Their About page states: All available HD illustrations belong to the public domain according to the European law and may be reused under the Creative Commons License. Please visit the website of the original contributors for further details by using the links provided on the illustration pages." This may not always be clear from the link on Commons file descriptions: File:Parsonsia alboflavescens 123145.jpg links to [plantillustrations.org], which, at the page bottom, links to the Internet Archive scan, where the original image can be found, i.e. here. So the short answer is yes, for illustrations. However, photographs on the site appear to not be free, as they require contacting the site admins to request permission. --Animalparty (talk) 19:22, 12 February 2020 (UTC)

┌─────────────────────────────────┘
@Animalparty: And you're prepared to take the word of every third-party site that claims its hosted content is PD? And if the images all "belong to the public domain according to the European law", then why must "the Creative Commons License" be used? Which one? Alarm bells should already be ringing at such bogosity.

Yes, the site is a source of Public Domain images, as your solitary example shows, but not all of its image are PD. Let's look at the works in question:

  1. File:Strychnos madagascariensis02.jpg was recently deleted by as a copyvio, by User:Túrelio, after I tagged it as such. It was apparently published in 1984, and there was "no evidence that creator died >70 years ago".
  2. File:William Edward Trevithick00.jpg was recently deleted by as a copyvio, by User:Túrelio, after I tagged it as such. Its creator died in 1958.
  3. The creator of File:Cadaba aphylla00.jpg died in 1973. Paul venter believes it is {{PD-old-70-1923}}, and has removed the copyvio tag I added, saying "The plate is from Rudolf Marloth's Flora of South Africa, a volume which he wrote and for which HE commissioned artwork which became HIS copyright. The PD-old-70-1923 permission therefore applies since Marloth died in 1931.". The linked page at plantillustrations.org currently shows no image.
  4. The named creator of File:Crassula perfoliata00.jpg died in 1967. Paul venter removed the copyvio tag I added, and added {{PD-South-Africa}}, whose only clause for non-anonymous/ pseudonymous artworks is "It is ... created under the direction of the state or an international organization and 50 years have passed since the year the work was published." The linked page at plantillustrations.org currently shows no image, and caries the text "Copyright reserved".

In the light of 3 and 4, and Paul venter's note on my talk page telling me to "kindly make sure of your facts before causing more trouble", perhaps this belongs on the admin noticeboard. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 19:41, 12 February 2020 (UTC)

@Pigsonthewing: And you're prepared to make snide, sweeping generalizations based on a single event? I figured there would be exceptions, and of course, no third party source should be taken completely at face value or as an authority when alternative sources conflict. This goes for Internet Archive files posted Flickr Commons, some of which are erroneously "public domain" because someone mislabeled a journal with the wrong date. Many third party sources understandably use the Public Domain guidelines of the country they dwell in, unlike Commons' more restrictive demand that all content must be free in every jurisdiction. When plantillustrations.org provides links, or even text citations, those sources should be investigated to ascertain status if in doubt. We can and should use our brains. --Animalparty (talk) 20:02, 12 February 2020 (UTC)
"snide, sweeping generalizations"? Where? You were quite happy to answer the OP's question with "So the short answer is yes, for illustrations", making no mention of the exceptions you claim to anticipate, and to uncritically quote plantillustrations.org's farcical prose. And this from someone whose user page says they are a "licence reviewer"... Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 20:09, 12 February 2020 (UTC)
Point of clarification: Commons requires media to be free in the US and in the country of origin, not in every jurisdiction (per COM:L#Interaction of US and non-US copyright law). Strictly speaking, Commons could probably get away with only requiring things to be free in the US, since that's where the servers are hosted (just as websites hosted outside of the US need only abide by the laws of their respective countries), but the additional requirements are to ensure files are maximally reusable. clpo13(talk) 20:17, 12 February 2020 (UTC)

┌─────────────────────────────────┘
Here's anther one:

Creator died in 1959; tagged by Paul venter as {{PD-South-Africa}}. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 20:31, 12 February 2020 (UTC)

...and Paul venter is now edit warring to remove the copyvio template from File:Crassula perfoliata00.jpg and also edit warring to remove it from File:Cadaba aphylla00.jpg. I'm going to post a pointer to this discussion on the admin noticeboard. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 19:06, 13 February 2020 (UTC)

In view of the conflicting opinions expressed above I feel that the discussion should be taken up a level or more in order to solicit views from more experienced and knowledgeable Wiki users. Paul venter (talk) 13:43, 14 February 2020 (UTC)
There is no real conflict of opinions. I wrote inaccurately, and overlooked the outliers which are causing controversy. plantillustrations.org is not the arbiter of Commons policy, and what is public domain in their jurisdiction may not be public domain in the work's country of origin, and thus not be acceptable for hosting on Commons. See Interaction of US and non-US copyright law. Claims to public domain require sufficient evidence. When clearly observable facts (e.g. death date of artist, date and country of publication) contradict third-party claims to public domain status, in the absence of compelling counterclaims, we can use our judgement remove them from Commons. --Animalparty (talk) 18:37, 15 February 2020 (UTC)

Does no-one else care about these images being falsely labelled as PD? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 10:10, 19 February 2020 (UTC)

There's no point edit-warring over a copyvio template. The next step should always be to go to a DR. The VP does not establish precedent either way, it's just a chat. -- (talk) 10:14, 19 February 2020 (UTC)
The {{Copyvio}} template says "l: If you think that the file does not meet the criteria for speedy deletion, please open a regular deletion request and remove this template. ". Why, then, is it OK for Paul venter to remove the template without stating a DR, and without adding any template that correctly justifies the file's inclusion on Commons? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 10:08, 20 February 2020 (UTC)
Anyone can remove speedy tags, once. Anyone can instead escalate to a DR if they are unhappy with the speedy tag, or wish to escalate after removal. As folks will have different understandings of what is sufficient to validate copyright, a DR is always the higher path and, in my view, is highly preferable as such discussions can establish good precedent for other files with similar issues.
Repeatedly removing speedy tags on the same file, or re-applying them after removal, will look like edit-warring regardless of who is "right" about copyright. -- (talk) 10:18, 20 February 2020 (UTC)
I don't dispute that "anyone can remove speedy tags". However, anyone doing so is supposed, according to the template itself, to start a DR. Is that correct, or not? If not, then the template text should be modified accordingly. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 16:09, 20 February 2020 (UTC)
Why is File:Crassula perfoliata00.jpg falsely labelled as PD? It is from 1922. It's from a life+50 country by an author who died more than 50 years ago. If you want to bring them up to DR, go for it.--Prosfilaes (talk) 23:29, 19 February 2020 (UTC)
Well, look who just added a template to that effect. Your comment does not reflect the state of the image page at the time I made my above post, when, again as stated above, Paul venter had applied only {tl|PD-South-Africa}}, whose only clause for non-anonymous/ pseudonymous artworks is "It is ... created under the direction of the state or an international organization and 50 years have passed since the year the work was published.". The creator died, according to the file description and as stated above, in 1967, not 1956. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 10:08, 20 February 2020 (UTC)

February 13[edit]

Unidentified cameras & smartphones[edit]

  •  Done Sony α7 III

  • TVlogic vfm-058W

Could someone identify the devices on these photos? I am sure that there is an appropriate category. Thank you! --Edelseider (talk) 15:36, 13 February 2020 (UTC)

Well, I've done the easy one (File:Opening of April Plenary - the last of the current legislation term (32672428877).jpg). --bjh21 (talk) 15:46, 13 February 2020 (UTC)
Category:Unidentified cameras? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 16:49, 13 February 2020 (UTC)
File:Social media live interview with Bernd Lange.jpg may be a recent iPhone model. --ghouston (talk) 06:06, 14 February 2020 (UTC)
@Pigsonthewing: you are right, but that category is limbo! I trust the nerds around here to be faster. :) --Edelseider (talk) 07:56, 14 February 2020 (UTC)
The monitor in #2 was easy to find, but I don't think we have an appropriate category for external video monitors yet. --El Grafo (talk) 12:42, 14 February 2020 (UTC)
Aren't 3 and 4 just iPhones on tripods using non-Apple software for video recording? --Richard Arthur Norton (1958- ) (talk) 01:39, 15 February 2020 (UTC)

February 14[edit]

Type of traffic signal[edit]

Do we have a category for this sort of traffic signal? I couldn't find anything appropriate. - Jmabel ! talk 02:01, 14 February 2020 (UTC)

I've only ever heard them called "arrow boards" or "arrow panels", and I don't think we have a matching category. It's closer-related to a non-electronic sign or a Variable-message sign than to a traffic signal. Pi.1415926535 (talk) 03:42, 14 February 2020 (UTC)
At the English Wikipedia there is this (for bigger screens), and if it's provisional it's a part of a smart work zone (again, for bigger screens). I've heard people call them "Matrixborden" and "Aktieborden" in Dutch. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 11:53, 14 February 2020 (UTC)
Well, Matrixborden would presumably just be "matrix boards" in English, and we do use the term "matrix signal" for some smaller, similar signs. Anyway, I bet we have quite a few photos of this type of sign, and if someone wants to work on categorizing them better, please feel free. - Jmabel ! talk 16:24, 14 February 2020 (UTC)

Protection message on pages with template protection[edit]

Templates that have a protection level of Template editor currently displays a message "This page is currently semi-protected, and can be edited only by established registered users.", but this is not accurate. The template is not semi-protected and can't in fact be edited even by established, registered users. An example is Template:Taken on. As per the templates protection log, this template can only be edited by admins or template editors: "Allow only template editors and administrators". This message is confusing and wrong, and should be updated to take into account the new user group that was introduced last summer. TommyG (talk) 08:41, 14 February 2020 (UTC)

Commons:Twinkle[edit]

Is anyone intersted in maintaining the Commons:Twinkle tool? That page is marked as an inactive project, and the script does not seem to work. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 11:38, 14 February 2020 (UTC)

Upload Wizard woes[edit]

Tracked in Phabricator
Task T244836

For a couple of weeks or more, I've been having great difficulty using the Upload Wizard for sets of images - it typically times out at the "select images" stage, sometimes on the first or second lot, even if I only add them 4 for 5 at a time.

I know about Pattypan, but it often not worth using for smaller batches.

Is there a known issue/ Something I can do to fix this at my end? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 14:36, 14 February 2020 (UTC)

I'm finding that multiple concurrent uploads often all fail, whereas consecutive uploads (Add another file) generally work. I'm guessing this is a resource problem. Rodhullandemu (talk) 14:55, 14 February 2020 (UTC)
Hey Andy, please see Task 244836 on Phabricator (and for background this discussion on the German Forum). I was able to upload four images with Safari on MacOS two days ago (I usually use Firefox), and Magnus reported he succeeded with Opera, so this might be a Firefox problem. --Frank Schulenburg (talk) 16:34, 14 February 2020 (UTC)
Thank you. I'm using Firefox, FWIW. I uninstalled Opera, and wont be reinstalling it, for this reason. I'll try other browsers, and report back. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 17:45, 14 February 2020 (UTC)
After small amount of testing, I found it fails in the same way in PaleMoon (a fork of an earlier version of Firefox) and works without issue on Chrome, and on MS Edge. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 17:57, 14 February 2020 (UTC)
Sounds like an issue with the rendering engine that Firefox and Pale Moon use (respectively, Gecko and Goanna, a Gecko fork). The other mentioned browsers – Chrome, the newest Edge, and Opera – are based on Chromium and use the Blink engine. If you need to use a Chromium-based browser for mass uploads to work but want something privacy-focused like Firefox, I'd recommend Brave. In a similar vein, if anyone's a fan of Opera but doesn't like the direction the company is heading (see Andy's link above), Vivaldi is a good alternative. clpo13(talk) 19:03, 14 February 2020 (UTC)
Yes, I can get it to work if I add images one at a time. But that's painful... Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 17:46, 14 February 2020 (UTC)
Look at the upload timestamps from these 1000 files in User:C.Suthorn/liste/7. They are all from the same event. At the time I was not able to upload more than 10 files with the upload wizard. Sometimes only FF worked, sometimes FF not at all, sometimes not windows, but linux, sometimes only iOS. It is the same error since then. It is sporadic, it works for month, than not at all, it works for me, but not for someone else or vice versa. The uploadwizard has severe problems, that have never been solved, instead new features (SDC) been added. --C.Suthorn (talk) 20:06, 14 February 2020 (UTC)

int:filedescr[edit]

This edit brought to my attention that {{int:filedescr}} is not any longer transcluding the word "Summary" in the current UI language. This was a recent change, when did it happen exactly?, and why? Wouldn’t it be better to have a bot replacing it it with the (now) correct {{int:filedesc}} instead of adding it to what has become useless? (I understand why the bot is doing what it’s doing, but it is still wrong — @Schlurcher: ping!) What about keeping both, any of them redirecting to the other? -- Tuválkin 17:58, 14 February 2020 (UTC)

Are we sure it ever worked? Normally these things are defined in code, but I can't find any references to filedescr ever being a thing and the phrase only appears on 4 images at commons. Maybe it was just a typo. Bawolff (talk) 23:12, 14 February 2020 (UTC)
— Speravir – 02:11, 15 February 2020 (UTC)
I fixed these images, for reference links to my edits: Special:Diff/387544964/394565612, Special:Diff/181278162/394565772, Special:Diff/278572408/394565946 and Special:Diff/394231466/394565239. — Speravir – 02:21, 15 February 2020 (UTC)
MediaWiki:Filedescr doesn't seem to have ever existed, MediaWiki:Filedesc works just fine. I think Schlurcher just made a typo? Multichill (talk) 12:11, 15 February 2020 (UTC)
The user who uploaded the image made the typo, so my bot did not realize the heading and added the appropriate one. As there might be lots of different ways to misspell this template, I think there is not much I can do. --Schlurcher (talk) 13:54, 15 February 2020 (UTC)
  • Thank you, Schlurcher and everybody who looked into it. It’s a typo, then, and a seldom one, not a widespread variant. -- Tuválkin 03:47, 16 February 2020 (UTC)

February 15[edit]

Wikimedia 2030 community discussions: Last week begins[edit]

We are entering the last lap of the discussions on the Wikimedia 2030 strategic recommendations. Until next Friday, February 21, you can share your feedback, questions, concerns, and other comments.

In my last 2 messages on this village pump, I described how the recommendations were created, the role of your input, and the next steps. This time, let me describe just one selected recommendation, one that sounds to be particularly close to the activities on wiki: 'Improve User Experience'.

It states that anyone, irrespectively from their gender, culture, technological background, or physical and mental abilities, should enjoy a fluid, effective, and positive experience during both the consultation and contribution to knowledge. This recommendation is, among others, about the design improvements, user interface, but also training and support programsdedicated resources for newcomers, and, what I personally find especially interesting, mechanisms that allow finding peers with specific interests, roles, and objectives along with communication channels to interact and collaborate.

Please comment on the recommendations' talk pages. What do you think about this and other recommendations? Should some points be improved, removed, or added?

If something is not clear, please ping me. I will write back as soon as I can.

SGrabarczuk (WMF) (talk) 14:43, 15 February 2020 (UTC)

This isn't a productive comment, but "...during the...consultation...to knowledge" is some interesting phrasing. Bawolff (talk) 15:44, 15 February 2020 (UTC)
This isn't a productive comment either, but based on the illustrations for the 'recommendations' why are Wikimedians always fat white guys who use expensive Apple iMac's to look at Wikipedia? -- (talk) 19:21, 15 February 2020 (UTC)
Good question. I don't know! This isn't a productive response either, but thankfully, I'm skinny and don't have any Apple device :D
But jokes aside, @Bawolff, : do you have productive comments, like you believe something important related to the UX (user experience) was missed? Keep in mind this is the strategy, so we're talking about visionary thinking now. SGrabarczuk (WMF) (talk) 21:08, 15 February 2020 (UTC)

@SGrabarczuk (WMF): I have mentioned this many times before, but WMF employees seem to really love using the word "collaborate", probably because it's super popular in American English. As no doubt you are personally aware, this word has historic negative overtones in Europe (thanks Nazi collaborators), and when talking to an international community it is easily replaced with phrases like working collegially or even plainer English like "working together".

If the word "collaborate" or variations are built into the recommendations, do let me know so I can keep on raising this where it's in use, even if the chance of being heard is very low. Thanks! -- (talk) 19:54, 15 February 2020 (UTC)

Thanks, @: yes, I'm well aware of that issue in my language. I didn't know it's the case in other languages, though. FYI, I'm not a WMF employee, and those who wrote these recommendations aren't WMF employees either. I'll report your feedback, and we'll see what the result will be. SGrabarczuk (WMF) (talk) 21:08, 15 February 2020 (UTC)
I am a german nativ speaker and would say that we use the term "collabroative work"(kolaboratives arbeiten) and do not accociate it with anything negative. But the "community leader" term is definitly problematic. --GPSLeo (talk) 21:15, 15 February 2020 (UTC)
In Spanish the term "collaborative work" (trabajo colaborativo) lacks any negative connotation. Strakhov (talk) 13:40, 16 February 2020 (UTC)

I made a clumsy visual representation of the connections between the recommendations (data taken from the sections called Connection to other recommendations). I didn't take into account the cases when a recommendation is connected to all the others. Anyway, I leave making the conclusions to you. In addition, I'm sharing a cloud with the most frequently used words in the recommendations. SGrabarczuk (WMF) (talk) 23:54, 15 February 2020 (UTC)

200.000+ photos of Onroerend erfgoed in Flanders[edit]

The Flemish organization for Immovable Heritage opened up their photo collection. I uploaded most of the photos. This is addition to the photos we already got as part of Wiki Loves Monuments. All the photos for which an identifier was supplied use {{Onroerend erfgoed}} and are in (subcategories of) Category:Onroerend erfgoed in Flanders. Some of these subcategories could use some attention to sort them out. For the photos without an identifier I created Category:Possible onroerend erfgoed based on Category:Possible Rijksmonumenten. I hope some of the people who are actually from the area will help sort these out. Enjoy and I hope more of these kind of photo collections get opened up. Multichill (talk) 16:52, 15 February 2020 (UTC)

cross wiki upload with 40 categories (including body modification in Iran, Myanmar, Ivory Coast, Nepla, Indonesia, Afghanistan) does not ring an alarm bell for being somewhat questionabel?[edit]

File:GOLDY PRINCES WAND.jpg was cross-wiki uploaded with the categories: Category:Fetish models Category:Fetish clothing Category:Fetishism Category:Fetish figures Category:Fetish models from the United States Category:Fetish Barbie Category:Fetish clubs Category:Fetishes in the Musée du quai Branly Category:Fetish women of Dahomey Category:BDSM Category:BDSM whippings Category:BDSM cages Category:BDSM triskelion symbols Category:BDSM furniture Category:BDSM whipping Category:BDSM spanking Category:BDSM equipment Category:BDSM humiliation Category:BDSM symbols Category:Piercing Category:Piercing jewellery Category:Piercing guns Category:Piercing saws Category:Piercings Category:Piercing nozzles Category:Piercing tools Category:Piercing studios Category:Prince Albert piercings Category:Prince's wand Category:Body modification Category:Body modification in art Category:Body modification in Indonesia Category:Body modification in Japan Category:Body modification in East Timor Category:Body modification in Nepal Category:Body modification in Iran Category:Body modification in Myanmar Category:Body modification in Ivory Coast Category:Body modification in Afghanistan

(not the first time the user did something like that) and no bot, filter, mechanism or vandal hunter takes notice?????? --C.Suthorn (talk) 19:06, 15 February 2020 (UTC)

Implicitly this is a complaint about the uploads from @M-Spanky:. It's a courtesy to let them know.
The uploads seem spammy, but the rationale for deletion is because copyright looks super weak. Where published on YouTube, there is no suitable license, so a better statement is needed. If M-Spanky wants to improve commons with images of body art, that's super, but copyright has to be clear. -- (talk) 19:17, 15 February 2020 (UTC)
The uploads seem spammy because they are spammy. The same user was previously blocked as MasterSpanky. Abdo4 is the same person. These images should all be deleted as advertising and the pages created on Wikipedia cleaned up. World's Lamest Critic (talk) 05:09, 16 February 2020 (UTC)

From my side this is neither about copyright or a specific user. It is about UI, Categories, consistency: It is complicated to choose categories in MW, and it is strange if such many categories are attached to a file. Also categories are contradictory. There could (and should?) be a bot and/or filter and/or mechanism in the MW software that notifies (by a category or else) if something like this happens, as it will probalby need manual correction in some way. --C.Suthorn (talk) 06:22, 16 February 2020 (UTC)

BTW: Should the files of the user be kept: The category they belong to is Category:Penis plug --C.Suthorn (talk) 06:28, 16 February 2020 (UTC)

  • It's a commercial promotion. It's an SPA promoting their 3D art on a Youtube channel. See:their en.wiki contributions ~ R.T.G 11:25, 16 February 2020 (UTC)

The VP is not the right place for a complaint about the uploader or the upload batch. If you wish to discuss why the files should be deleted, please consider contributing at Commons:Deletion requests/Files uploaded by M-Spanky. Further action may not be needed. -- (talk) 11:45, 16 February 2020 (UTC)

February 16[edit]

Category:Leuke kome[edit]

Based on its name, Category:Leuke kome should contain files related to a settlement called Leuke Kome. The category is however entire made up of regional maps that show Leuke Kome as just another among many other places. How appropriate is it to categorise such zoomed-out maps according to the places they show? If appropriate, I foresee a very long list of categories for each map. --HyperGaruda (talk) 06:23, 16 February 2020 (UTC)

I am not sure why the maps were placed int this category. There may exist some special reason. The maps are historical after all. Otherwise maps should not be placed into settlement categories. Ruslik (talk) 20:22, 16 February 2020 (UTC)

Batch uploading[edit]

Hi everyone. I know how to batch upload from Flikr, but I've found a Complete gallery with all pages from all issues of the magazine Shidai Manhua/Modern Sketch, and I believe it would be beautiful (and easy to do if automathic) to have uploaded all pages in Commons.--TaronjaSatsuma (talk) 10:39, 16 February 2020 (UTC)

See Commons:Batch uploading. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 21:01, 16 February 2020 (UTC)
@TaronjaSatsuma:, well, if all these images are free and if the copyright © owner has uploaded them, then you can very easily import to to Wikimedia Commons using the Flickr2Commons tool (or just click here). --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 22:03, 17 February 2020 (UTC)
Thanks both @Donald Trung: and @Pigsonthewing:. I'll try Commons:Batch uploading because it's not uploaded in Flickr.--TaronjaSatsuma (talk) 10:25, 18 February 2020 (UTC)

Wikipedias featured picture today[edit]

Hello, on looking at File:Dharmaraya Swamy Temple Bangalore edit1.jpg on the en.wiki main page today I couldn't believe the full image was going to be detailed enough for a featured picture. It is, but the lighting is incredibly dull. Also it could stand a slight anti-clockwise rotation. I did not expect to be able to upload a new version while it was on a main page, but the upload system let me try. It failed after the upload, however it said I could request an administrator to do the upload at Commons:Requested updates to protected images. That page doesn't get a lot of response. I have edited a version of the picture in GIMP which ups the brightness and contrast by 30% each, rotates it about 0.45% anti clockwise, and balances a cropping out of the lamppost on the right hand side, and cropped just a sliver off the bottom and left to balance the framing... It's a very minor edit which is unlikely to be questioned usually, but it would be best done today while it is on the main page..? Anyone fancy doing it? I propose this alternative: File:Proposed edit to Dharmaraya Swamy Temple Bangalore edit1133.jpg ~ R.T.G 11:14, 16 February 2020 (UTC)

Mmmh, you've lost quite a bit of detail in the highlights there … --El Grafo (talk) 11:37, 16 February 2020 (UTC)
Such as? ~ R.T.G 11:49, 16 February 2020 (UTC)
I don't understand... I did edit one very small part of the picture... I didn't expect it would be noticeable.. however what you have stated here, overall, I have only changed the brightness and contrast and smudged one tiny piece of it... I've cut out the lamppost. The elements I chopped out had no significant detail except a lamppost? ~ R.T.G 11:52, 16 February 2020 (UTC)
Well it's not very important but the picture definitely looks very dull on the main page and has to be zoomed in to full size just to see that it is in fact the processing rather than the scene which is lacking. ~ R.T.G 11:53, 16 February 2020 (UTC)
Agree that the photo is dull in tone and annoyingly skewed. However this VP is not the right audience to have an effect on what happens on the en.wp main page. -- (talk) 12:40, 16 February 2020 (UTC)

Rotating picture?[edit]

When I click at the 1,584 × 2,816 pixels version of this picture, the picture rotates 90 degrees. Does anyone know how can this be fixed? Huldra (talk) 23:24, 16 February 2020 (UTC)

I can't replicate the problem using Chrome or Firefox browsers. Clearing the cache on your browser might help. --Animalparty (talk) 17:13, 17 February 2020 (UTC)
I have cleared the cache: no change. I am using Safari -does other Safari users here experience the same problem? Huldra (talk) 20:29, 17 February 2020 (UTC)
No problem with Safari 11.1.12. Wouter (talk) 20:35, 17 February 2020 (UTC)
I have Safari 13.0.4, and it still rotates...Huldra (talk) 20:43, 18 February 2020 (UTC)

February 17[edit]

Best practices for the New York Times archive[edit]

What are the best practices for the New York Times archive that is in the public domain? Should we store the pdf file or the jpg/png version? Should we trim off the copyfraud notice or leave it on? --Richard Arthur Norton (1958- ) (talk) 18:44, 17 February 2020 (UTC)
I don't think there are any best practices on Commons for any textual archives. There is some guidance at File types: Textual formats, Project scope: PDF and DjVu formats and Help:DjVu. For indexing public domain sources on Wikisource, see s:Help:Digitising texts and images for Wikisource (I believe they prefer complete magazine/issue/book uploads, from which individual articles can be gleaned, rather than isolated clippings). In my opinion, if a scanned image has reliable source info in metadata (i.e. file description), there is no valid reason to keep the New York Times notice: the articles are public domain, the notice is simply tangential and misleading noise irrelevant to the text. --Animalparty (talk) 19:59, 17 February 2020 (UTC)

Disable pre-2011 "wg" JavaScript variables[edit]

Hi,

Almost ten years ago (in 2011), the mw.config.get mechanism was introduced in MediaWiki's JavaScript runtime. This replaced the old way of accessing site information from MediaWiki, where each piece of information was its own global variable mixed in with all other programs bindings and variables. The new way grouped them together to occupy only a single variable, the mw binding. The example below illustrates what the new code looks like vs the old:

// Old
if (mw.user.isAnon() &&
    wgUserLanguage === 'en'
) { … }

// New
if (mw.user.isAnon() &&
    mw.config.get('wgUserLanguage') === 'en'
) { … }

To find out if a gadget or user script that you use is affected by this change, open the JavaScript console in your browser. If you see warnings like "Use of "wgPageName" is deprecated. Use mw.config instead.", then a script or gadget you are using might stop working soon. If you know which gadget is responsible, report it to its talk page. Otherwise, ask for help by commenting below, or at Commons:Village pump/Technical, or reach out to T72470 on Phabricator. See also these Search results which show that some site-wide scripts might be affected, although it's possible some of these are already broken and/or no longer used. I've already started to go through some of these myself.

I'd like to propose for Wikimedia Commons to be one of the earlier wikis to try disabling this compatibility feature so that we can find out sooner rather than later what we need to fix. During this time it will be easy to get us switched back if something is broken, even if the affected script is not very important overall. This will be more difficult if we wait! --Krinkle 23:19, 17 February 2020 (UTC)

February 18[edit]

US Aerial imagery[edit]

I found this imagery I'd like to upload on commons that I'd like to upload to Commons. The article claims, that the image was created by US armed forces which would imply that it's PD as of Template:PD-USGov. Nonetheless i can't find any US-american source. Is it possible to upload the image grabed from the german newspaper? -- Dr.üsenfieber (talk) 12:44, 18 February 2020 (UTC)

Category:Pages with local coordinates and missing SDC coordinates[edit]

Hello, I don't quite understand what to do to get rid of this category in my uploads? --A.Savin 16:48, 18 February 2020 (UTC)

Neither do I. It looks like an awful way to report this. @Jarekt: why would you want a hidden category for this, rather than running a report only you need it? -- (talk) 17:41, 18 February 2020 (UTC)
For years we had hidden categories like Category:Pages with local coordinates and mismatching Wikidata coordinates or Category:Pages with local coordinates and matching Wikidata coordinates. Now that {{Location}} and {{Object location}} templates can fetch the coordinates either from wikitext or from SDC, it makes sense to track it the same way. Also, since numerous users are moving metadata from wikitext to SDC, tracking categories like that are useful for tracking which files had their metadata moved, which had not, and for which files it was done badly (Category:Pages with local coordinates and mismatching SDC coordinates). The category is hidden so it is less visible in general and visible only to logged-in users who have selected to "Show hidden categories" in their appearance preferences. If such categories are not desirable than it is pretty easy to unselect that option. --Jarekt (talk) 03:15, 19 February 2020 (UTC)
Thanks, Jarekt, for the explanation. I've been wondering about what that category means as well. So, let's say, I uploaded the image Kuskov House and Orthodox Chapel at Fort Ross, February 2020.jpg. What would be the appropriate "SDC coordinates" that I'd have to add in order to make the category disappear? --Frank Schulenburg (talk) 03:27, 19 February 2020 (UTC)
Frank Schulenburg, You can add coordinates of the point of view (P1259) property to SDC using GUI. It is still a bit clunky but it works. A new version is in the works, see phabricator:T227116. --Jarekt (talk) 13:23, 19 February 2020 (UTC)
Was there any consensus that files with a location template require SDC coordinates? And what is the point of SDC coordinates, is there a help page?
I may be missing something, but this looks like pointless categorization (of 3,195,703 files and at least 83,000 are my uploads) when a report can be pulled of these were anyone wishing to do something with these files. -- (talk) 10:42, 19 February 2020 (UTC)

Looking at this slightly further, this category has been added to over 3 million files, but there was no community discussion. It has been added to templates in a way that means that only administrators have access, and no non-sysop editor is allowed to remove it from files. These are now built into location templates effectively warning all users that their files lack SDC coordinates, when there has been no consensus that hiding coordinate data inside obsure and non-standard SDC fields outside of wikitext is either sensible or useful for this project.

Jarekt, could you advise how to reverse this and who is responsible for the changes? The burden to achieve consensus for mass changes like this is on the people making the change. There should never be a burden imposed to reverse it. Thanks

Commons:Categories for discussion/2020/02/Category:Pages with local coordinates and missing SDC coordinates

-- (talk) 11:03, 19 February 2020 (UTC)

Hi Jarekt To my latest photo I've added the property as you adviced, but the category is still there. So please adress my question: a) What to do to get rid of the category; because for readability reason I try to keep only as few categories as really necessary? b) What is the added-value for a single photo if the coords are in the SD instead of file description? c) If it's necessary, may a bot take the coords from file description (most of my photos have coords) and copy it to SD, because I cannot manage it all by hand, thank you. --A.Savin 13:35, 19 February 2020 (UTC)
A.Savin, The category in your file switched to Category:Pages with local coordinates and matching SDC coordinates, as opposed to Category:Pages with local coordinates and mismatching SDC coordinates. That is for people who like to verify that the transfer was correct. I agree that bot transfer of coordinates would be preferred over manual one (less mistakes for one thing). I think it would be great is someone run such bot. There are several users transferring metadata from files to SDC in a batch mode, User:Multichill using User:BotMultichillT or User:XRay using User:XRayBot come to mind. I would talk to them to see how much work it would be to update your files. --Jarekt (talk) 14:12, 19 February 2020 (UTC)
Category:Pages with local coordinates and matching SDC coordinates??? Are we really going to need millions of files marked to say "this file appears not to have a particular error"? - Jmabel ! talk 17:39, 19 February 2020 (UTC)
Agreed, this is craptacular.
If you want crappy pseudo-categories nagging everyone about SDC (and frankly putting us off ever cooperating with SDC related projects) then make a formal proposal and explain exactly why Commons must suffer this crappy solution, when all you have to do instead is pull a report when, and only when, you actually are going to work with the data.
Thanks so much for your understanding. -- (talk) 17:42, 19 February 2020 (UTC)

February 19[edit]

Correction of file title[edit]

I have tried to make a very minor correction to the title of the follwing uploaded file.

File:'Preparing Tea'. Jane Maria Bowkett (1837-1891) Signed with a monogram. Oil on canvas.jpg.

Namely inserting a full-stop after the bracket (before the word 'Signed'). So far it has been declined. Can this correction be made?BFP1 (talk) 08:35, 19 February 2020 (UTC)

Commons:File_renaming lists all cases when renaming is possible. A missing full stop does not fit into any of them. Ruslik (talk) 14:46, 19 February 2020 (UTC)
Criterion #1 is possible and requests coming from the original uploader are usually not declined. As a file mover I would be happy if uploaders who want to rename files they have uploaded themselves would always choose criterion #1 even if other criteria may seem to fit too. --Andreas Stiasny (talk) 17:10, 19 February 2020 (UTC)
Done. --ghouston (talk) 04:30, 20 February 2020 (UTC)
@Ghouston:. Thanks BFP1 (talk) 07:37, 20 February 2020 (UTC)

Guidance on category naming (specifically, those starting with a quantity)[edit]

Joshbaumgartner started a discussion at Category talk:Groups about standardizing category names for groups of objects. Only one other person commented and the discussion was closed. Joshbaumgartner has begun renaming categories and recategorizing images based on that discussion. When I noticed that he had moved Category:Two cats to Category:2 cats, I started a discussion on his talk page. Standard English usage is to spell out quantities if they are at the beginning of a sentence or title. So a picture of 2 cats would be in category:Two cats but a package of 2 donuts would (hypothetically) be in "category:packages of 2 food items". I understand Joshbaumgartner's reasoning and I am sure he is doing this with the best intentions, but to prevent future disagreements, can we get some other opinions about this change? Thanks. World's Lamest Critic (talk) 22:41, 19 February 2020 (UTC)

The original discussions (there were two CfDs on this issue) were at Commons:Categories for discussion/2017/11/Category:Groups by size and Commons:Categories for discussion/2019/10/Category:Groups. Josh (talk) 23:15, 19 February 2020 (UTC)
A new CfD for this has been opened at Commons:Categories for discussion/2020/02/Category:Groups of cats to further discussion. Josh (talk) 23:15, 19 February 2020 (UTC)
Please discuss it here instead. I started this discussion here so that we could get more input and visibility. Let's get consensus on the general points first. World's Lamest Critic (talk) 23:35, 19 February 2020 (UTC)
I would agree that this is of broad enough concern that we should have the discussion on the VP.
As for the outcome: I'd be happy with almost anything consistent. - Jmabel ! talk 00:24, 20 February 2020 (UTC)
To summarize the debate:
  • The value in spelling out the words is that it's more consistent with standard English, where starting a sentence/title with a numeral is usually considered awkward.
  • The value in using numerals is that they are shorter (particularly for higher numbers), potentially easier to use with templates, enable consistent use of one format across all categories (rather than the inconsistency of Category:Two food items and Category:Packages of 2 food items)
These both seem like valid arguments to me. Are there any other relevant points? - Themightyquill (talk) 09:06, 20 February 2020 (UTC)
Another advantage of numerals is that non-native speakers are more likely to get it right. - Jmabel ! talk 16:22, 20 February 2020 (UTC)
I'm fine with the awkwardness of starting category names with numerals, as long as there's no objection if someone wants to create category redirects that spell the numbers out. Note that I am not suggesting that we automatically create redirects for all such cases. --Auntof6 (talk) 19:26, 20 February 2020 (UTC)

February 20[edit]

Computer-Aided Tagging[edit]

How do I stop the Computer-Aided Tagging tool from sending me "alerts" about suggested tags?

Thank you,

      Tibet Nation (talk) 20:21, 20 February 2020 (UTC)
@Tibet Nation: visit this part of preferences, the fourth check box down, "Suggest tags for review." Keegan (WMF) (talk) 21:19, 20 February 2020 (UTC)

Eronous dates in structured data[edit]

It is important to keep a critical eye on dates. Some dates of picture taken are misleading, certainly with old postcards. The exact date is unclear. I cant read the writen date.Smiley.toerist (talk) 23:26, 20 February 2020 (UTC)

February 21[edit]

Retrieved from "[commons.wikimedia.org]" Categories:

Navigation menu

Personal tools

Namespaces

Variants

    Views

    More

      Navigate

      Participate

      In other projects

      Print/export

      Tools

      In Wikipedia

      Edit links