Commons:Village pump

Матеріал з Wikimedia Commons
Перейти до навігації Перейти до пошуку

Скорочення: COM:VP

Community portal
introduction
Help deskVillage pump
copyrightproposalstechnical
Administrators' noticeboard
vandalismuser problemsblocks and protections
↓ Skip to table of contents ↓       ↓ Skip to discussions ↓       ↓ Skip to the last discussion ↓
Village pump for your language:
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


 

Turkey Beypazarı district Hırkatepe Village pump. [add]
Centralized discussion
See also: Village pump/Proposals • archive

Template: Перегляд • Discuss  • Редагувати • Спостерігати

Зміст

December 10[ред.]

Multilingual file captions coming this week[ред.]

Hi all, following up on last month's announcement...

Multilingual file captions will be released this week, on either Wednesday, 9 January or Thursday, 10 January 2019. Captions are a feature to add short, translatable descriptions to files. Here's some links you might want to look follow before the release, if you haven't already:

  1. Read over the help page for using captions - I wrote the page on mediawiki.org because captions are available for any MediaWiki user, feel free to host/modify a copy of the page here on Commons.
  2. Test out using captions on Beta Commons.
  3. Leave feedback about the test on the captions test talk page, if you have anything you'd like to say prior to release.

Additionally, there will be an IRC office hour on Thursday, 10 January with the Structured Data team to talk about file captions, as well as anything else the community may be interested in. Date/time conversion, as well as a link to join, are on Meta.

Thanks for your time, I look forward to seeing those who can make it to the IRC office hour on Thursday. I'll add a reminder to this post once I confirm exactly what day captions will be turned on for Commons. Keegan (WMF) (обговорення) 20:18, 7 January 2019 (UTC)

Captions are scheduled to go live tomorrow, Thursday 10 January, between 15:00 and 16:00 UTC. The time window may change at the last minute, and the team my hold the deployment (or roll it back) if last minute problems occur. Should that happen I will keep you all informed, and I'll see you all at the IRC office hour tomorrow. Keegan (WMF) (обговорення) 20:13, 9 January 2019 (UTC)

Captions are live[ред.]

Captions can now be added to files on Commons. There's a bug with abusefilter sending errors to new accounts adding captions, the bug is being investigated and fixed right now. IRC office hours will be in a little over one hour from now, I look forward to seeing you there if you can attend. Keegan (WMF) (обговорення) 16:47, 10 January 2019 (UTC)

Is there a way to turn this off? The huges block that appears between the image and the file information is hindering me. Jcb (обговорення) 16:59, 10 January 2019 (UTC)
+1 I can't find a way to disable this beta feature in my preferences. Where/how to turn it off? --Te750iv (обговорення) 19:41, 10 January 2019 (UTC)
It's not a feature with a built-in disable as it's part of the file page. I imagine a gadget can do this, if someone is inclined to make one. I'm hearing some issues about the box being very large for people with many languages listed in babel boxes on their userpage; this was done by design based on how Wikidata functions (we had feedback that people wanted the same behavior). If this is a big deal for people, we can probably work something out to reduce the size of the box if Commons doesn't want the same behavior as Wikidata. I will note that future SDC releases like structured metadata in statements will be hidden behind tabs. This is one of the only features that shows directly on the file page. Keegan (WMF) (обговорення) 19:44, 10 January 2019 (UTC)
Make this edit to your user css to disable the box. Thanks. Mike Peel (обговорення) 19:48, 10 January 2019 (UTC)
Thank you Mike, I was coming over here to copy your link :) Keegan (WMF) (обговорення) 19:54, 10 January 2019 (UTC)
@Mike Peel: thanks, it partly works for me. The caption block is gone now, but the large "Structured data" heading still remains at the top of real file descriptions. --Te750iv (обговорення) 20:03, 10 January 2019 (UTC)
@Te750iv: You mean the "Captions" header? Try doing the same as before but for "mediainfo-captions-header", if that doesn't work then a screenshot would be useful as I'm not sure if we're seeing the same thing. Hopefully a css id can be added to the box soon, which will provide a better handle to use css/js to change the display of the box. Thanks. Mike Peel (обговорення) 20:11, 10 January 2019 (UTC)
@Mike Peel: tried, but has no visible effect. I use File:Anderson Japanese Gardens waterfall.jpg as a reference image. Is see "Structured data" (in h1 heading format) below the image and above the "Summary" heading. --Te750iv (обговорення) 20:22, 10 January 2019 (UTC)
@Te750iv: OK, try this. @Keegan (WMF): Does that header only show up if captions are already present? It doesn't appear at File:SGRT-01.jpg for example. Thanks. Mike Peel (обговорення) 20:27, 10 January 2019 (UTC)
@Mike Peel: I think so. I'll find out if that's intended behavior or a bug. EDIT: Phabricator ticket. Keegan (WMF) (обговорення) 20:39, 10 January 2019 (UTC)
@Mike Peel: thanks, now individual opt-out works. --Te750iv (обговорення) 20:36, 10 January 2019 (UTC)
Perhaps I am misunderstanding where to do this. Does this mean I should edit User:Jmabel/vector.css or something else? Because editing that accordingly is doing nothing for me. - Jmabel ! talk 00:57, 11 January 2019 (UTC)
Again, can someone give clear instructions on how to get rid of this? - Jmabel ! talk 05:01, 11 January 2019 (UTC)
@Jmabel: Maybe you are using a skin other than vector. Try entering the same piece of code at User:Jmabel/common.css. 4nn1l2 (обговорення) 05:07, 11 January 2019 (UTC)
Sho'nuff. Thanks. Now (independently of my use as an individual) if someone could make this so it was a thing you could readily toggle on & off, that would be very good. How could that possibly not have been part of the design of this?! - Jmabel ! talk 05:23, 11 January 2019 (UTC)
"If this is a big deal for people, we can probably work something out to reduce the size of the box if Commons doesn't want the same behavior as Wikidata." @Keegan (WMF): is THAT why Wikidata always shows me a long list of languages that are like gibberish to me? If only someone had told me! I've searched forever to figure out why it was behaving like this. (and failed) - Alexis Jazz ping plz 23:28, 10 January 2019 (UTC)
@Alexis Jazz: oh yikes, yeah, that's probably why. Keegan (WMF) (обговорення) 23:43, 10 January 2019 (UTC)
@Keegan (WMF): should I ask on Phabricator to ignore level 0 languages or where is this managed? - Alexis Jazz ping plz 23:46, 10 January 2019 (UTC)
That's probably a good idea, I'm sure you're probably not the only one dealing with that kind of cluttered interface mystery. Keegan (WMF) (обговорення) 23:51, 10 January 2019 (UTC)
Structured data caption feature box, bigger is better I guess
I also made a screenshot. - Alexis Jazz ping plz 21:47, 11 January 2019 (UTC)
Alexis Jazz, I do not see any Babel box on your user page in Commons, so apparently your Meta page info is used, right? My suggestion: Remove all these lang-0 entries, and add only the one(s) you really speak on a certain level. Change your Babel box to something like this (the key here is in the switch and String module usage):
{{#babel:en-N|fr-2|de-1|es-1|<!--
-->{{#switch:{{#invoke:String |match |{{int:lang}} |%w+}}
    |en=|fr=|de=|es=<!-- show nothing for spoken languages already added before -->
    |#default={{#invoke:String |match |{{int:lang}} |%w+}}-0
   }}<!--
-->}}
This works fine for me. — Speravir – 02:14, 14 January 2019 (UTC)
@Speravir: that's right, it somehow used the babel box from my global user page. I want to have all these lang-0 entries to make it clear nobody needs to complain to me in Chinese or Bulgarian when I replace an image on their wiki as part of regular maintenance. And Mediawiki shouldn't be using something on a user page as a preference setting. So my babel box is now botched, and everything is working fine once again. - Alexis Jazz ping plz 02:21, 14 January 2019 (UTC)
I started Commons:File captions − feel free to expand. Jean-Fred (обговорення) 12:09, 11 January 2019 (UTC)

This change is craptastic for Commons. Was any consensus established for this, or are Wikidata purists forcing this terrible half thought out implementation on us Commoners? -- (обговорення) 17:35, 11 January 2019 (UTC)

Meanwhile vandals didn’t hesitate for long to acquire the new tool. How can I take Wikidatan toys out of my watchlist? Incnis Mrsi (обговорення) 17:55, 11 January 2019 (UTC)

How can I get rid of these wretched annoying 'Captions' boxes - or at least, shove them down to the bottom of the page so I don't have to scroll for ages down every single image page to get to descriptions, categories, etc. PS I read @Mike Peel:'s comment above but I don't have a "css" (or if I do, don't know where it is, nor how to change it) - MPF (обговорення) 22:56, 13 January 2019 (UTC)

@MPF: Jean-Fred created two gadgets today. Go to your settings, gadgets section and activate either Hide captions or Collapse Captions.
— Цей непідписаний коментар додано Speravir (обговорення • внесок) 02:14, 14 January 2019 (UTC)
Eehm, signature forgotten, second try: ping @MPF. — Speravir – 02:37, 14 January 2019 (UTC)
Excellent, thanks! Done, success :-) MPF (обговорення) 09:42, 14 January 2019 (UTC)
They've reappeared, even though I've still got them 'hidden' in my preferences - how do I get rid of them again, please? - MPF (обговорення) 23:13, 12 February 2019 (UTC)

Good practice ?[ред.]

I am sligthly confused by the potential overlap between the description field and the caption. What are the good practices in that respect? Where can I find examples? — Racconish💬 17:07, 10 January 2019 (UTC)

Racconish, think of this new element as a brief description, rather than the sometimes expansive descriptions we tend to put in the Information template. Huntster (t @ c) 18:08, 10 January 2019 (UTC)
I get this, but if the description is already short, should we just repeat it? Or skip the caption? — Racconish💬 18:13, 10 January 2019 (UTC)
I can't speak to how others would use this but I will use it for the intended purpose of a caption which is to supplement media with words that provide a context. Something like "Information" may well include all kinds of extraneous details that shouldn't (e.g.) be inserted into an encyclopedia article alongside an image. —Justin (koavf)TCM 18:37, 10 January 2019 (UTC)
(Конфлікт редагувань.) Sure, if the description is short, then there's really no need. To be perfectly blunt, there's no need for these captions, period. Every scenario I can imagine is just as easily solved, and creates a more unified appearance, by simply editing the description page. If WMF really wanted to improve functionality, they would simplify the ability to add descriptions in different languages to the Information template that is already in overwhelmingly widespread use on the site. This new functionality just feels redundant. Huntster (t @ c) 18:40, 10 January 2019 (UTC)

Potential benefit from these "captions" is vague and don't worth this cluttering of pages. If description of some file is not understandable at a glance, you can edit it. No need for another field. Fields for these "captions" are a junk, it would be better to remove it. Sneeuwschaap (обговорення) 18:32, 10 January 2019 (UTC)

No, I don't get it either. Can anyone please explain: what is the added value of the new caption feature to the already existing caption in file description? Is it the fact that captions can be made multi-lingual? Obviously no, as file descriptions may be multi-lingual as well. Are the captions maybe visible on other projects now? If yes, I don't get the sense, because, as we know, captions in WP articles are often context-depending and may vary for the same picture. Is it now easier to create a caption? I don't think so either: for each language, the caption still has to be translated/added by hand, just the same way as in file description. So, what is exactly the point of this new feature, please? On the other hand, it looks very poor now that the caption block is placed below the file, so you cannot see anymore the picture and the description at the same time without having to scroll. Any way to turn it off? --A.Savin 18:37, 10 January 2019 (UTC)
From a technical standpoint, captions are like labels on Wikidata. They will be searchable through the API, making it easy to find/filter/pull captions from files as metadata. There are a lot of possibilities of what this can be used for, from filling in infoboxes, building lists for translation of important files needing a caption localized for a project or campaign, searching for and finding captions, etc. So in comparison to description templates, while they potentially contain similar data to a caption, their function and reuse purposes are very different. Keegan (WMF) (обговорення) 18:55, 10 January 2019 (UTC)
@Huntster, Racconish: sorry, forgot to ping above. Keegan (WMF) (обговорення) 18:57, 10 January 2019 (UTC)
I would still like to see some examples of good practices. — Racconish💬 19:04, 10 January 2019 (UTC)
+1 --A.Savin 19:12, 10 January 2019 (UTC)
Sure. It's up to the community to decide (probably at someplace like Commons:File captions?), but here's an example I made just now as a community member. File:201San_Mateo,_Rizal_Landmarks_17.jpg has a long description that goes "off topic" from describing what's in the file, including OSM links and a licensing summary of sorts. So, I made a simple caption from the first line of the description. This is an immediate kind of use case that comes to mind, I'm sure we can catalog more. Keegan (WMF) (обговорення) 19:18, 10 January 2019 (UTC)
Thank you. I have to say this is not a very clear example for me, as it took me a while and some blue links clicking to understand it. It would be appreciated to see some more examples of what to do and what not to do. — Racconish💬 19:33, 10 January 2019 (UTC)
(ec)That's still redundant and no good example. If the caption is too long and you are, say, using the picture in a WP article and need only its first sentence (like in your example), you just copy the sentence and add to caption in the article. There is no point to add an extra feature for it, let alone if the feature spoils the appearance of file pages on Commons. --A.Savin 19:36, 10 January 2019 (UTC)
As I've mentioned above, while captions may contain the same information as a description, from a technical standpoint the implementation and reuse applications are completely different. Keegan (WMF) (обговорення) 19:49, 10 January 2019 (UTC)
Keegan, I'm sorry, but this is horrible. I work in software development, and I know bad justification of bad design when I see it. This is a textbook example of that. (Hint: It's founded in implementation rather than use cases.) Commons talk:Abuse filter is already getting hit with reports from users who don't give a tiny rat's ass about your "implementation and reuse applications". Real reuse would be to give the APIs access to the existing descriptions. Disable this monstrosity, and please, for once, try to get it right next time. LX (talk, contribs) 01:41, 11 January 2019 (UTC)
+1. Sneeuwschaap (обговорення) 18:45, 11 January 2019 (UTC)
Would "SM Supermall in San Mateo, Rizal" be better or worse? Is it good or bad to have the same caption on two files? — Racconish💬 19:44, 10 January 2019 (UTC)
  • Using that same file as an example, this is what media file page curation looks like; I skipped the captions thingy (and it was there, I did it before this other edit), as I went from Cat-a-lot (yes, I have cats showing on page top) to wikitext editing. Better find a way to gather data to fill up this new thing from existing workflows or see it gathering dust and left unattended. -- Tuválkin 02:30, 11 January 2019 (UTC)

I would say the long term idea of that is to replace the image title with this caption to have the it multilingual and no problems with file-renaming. --GPSLeo (обговорення) 18:49, 10 January 2019 (UTC)

This is unlikely, as the file name is unique and cannot be replaced by a caption which may be the same for several files. --A.Savin 19:12, 10 January 2019 (UTC)
I mean that the name displayed everywhere can be changed the filename dose not change but it will only be used to embed this file in a Wiki. But I would prefer to replace the Filenames by IDs like on Wikidata, of course there have to be redirects at the current filenames then. --GPSLeo (обговорення) 19:18, 10 January 2019 (UTC)
Note that a unique ID, stored in a base, is created when you create a caption for the first time, that is already working like that, that is called "entity" here. But we should no more see it : a few more infos. In any case it makes the images unique, even with the same caption. Christian Ferrer (talk) 19:34, 10 January 2019 (UTC)
I know, but I think it is not usable for embedding the image in a Wiki jet. --GPSLeo (обговорення) 19:44, 10 January 2019 (UTC)

I get 4 lines for the captions: Nederlands, Deutsch, English and français. Why only these and not also Spanish? Why is after each language mentioned “Add a one-line explanation of what this file represents” and not in Nederlands, Deutsch and français? Wouter (обговорення) 21:07, 10 January 2019 (UTC)

@Wouterhagens: the lines are shown to you based on your babel boxes. If you add one for Spanish, it will show up too. This mirrors the Wikidata label functionality, I believe.
As to why the "Add a one-line..." is only appearing in English, some apparent issues are happening in syncing up with translatewiki.net, where MediaWiki system messages are translated. It's being investigated in order to be fixed, the instructions should be localized to language settings. Keegan (WMF) (обговорення) 21:12, 10 January 2019 (UTC)

These captions are a huge clutter imo, they should at least disappear when there is no info to show and/or show up below the standard infobox. --Trougnouf (обговорення) 21:47, 10 January 2019 (UTC)

I agree fully with you. The new tool in not integrated with the current description practices (the file name and the description field). As we have 3 methods how to describe the file, the description will be most likely incomplete and chaotic. --ŠJů (обговорення) 22:39, 10 January 2019 (UTC)

Just curious, but how are "Captions" structurally more beneficial than "Description"? I would imagine that "Captions" exist as a machine-readable format to help improve search engine results, but does that mean that machines will ignore “Description”? Do “Captions” work like tags the same way for example “#MeToo” works on Twitter? Why would one be included in “Structured Data” and the other shouldn't? Wasn't the whole point of structured data on Wikimedia Commons to organise everything? Wouldn't properties (like on Wikidata) fulfill this practice way better? --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 07:14, 11 January 2019 (UTC)

@Donald Trung: good question. Above I likened captions to Wikidata labels, a brief summary/description of the rest of the data contained within. Captions are stored as wikitext within Wikibase, and the structural benefit is in and will be in putting them in Wikibase with the rest of the forthcoming SDC data. Coming in the next month is the next feature releases, depicts and other statements, which is that part that truly starts to organize things. Following that, we'll fill out the rest of the structured data like what one finds on Wikidata, with licensing/copyright, attribution, and advanced search coming by the end of the year. In other words, caption is a single part of the whole features package for Structured Data on Commons, and they will work and play well together once the project is nearing completion. Keegan (WMF) (обговорення) 17:45, 11 January 2019 (UTC)
I have to agree with Herzi Pinki’s comment below here, it baffles me that SDWC is being applied only to the files and not the categories, it's as if the Wikimedia Foundation heard complaints about how categories are being used and then thought about a new way to completely circumvent categories altogether rather than reinvent how to properly use them. Why not just structure the way Wikimedia Commons categories are used and integrate them better with Wikidata categorisation. For example on Wikidata an instance should be able to be linked to both a Commonswiki gallery and a Commonswiki category, but to this day Wikimedia Commons is listed on Wikidata as one of “other websites” and clearly an afterthought, linking Wikimedia Commons categories and gallery pages with Wikidata pages would also structure which properties should (automatically) be added.
Furthermore in order for people to find the best and/or most relevant pictures in a large category tree the way files in all these sub-categories should be accessible without having “to hunt through sub-categories” could be realised by adding certain filters like “show all quality images”, the ability to see the entire category tree and navigate it, how organised and structured statistics of how many files there are in a certain category and/or all of its sub-categories. There are many ways to add structured data to categories and it would eliminate the need to add certain properties to every file. I have the impression that the Wikimedia Foundation just wants to completely do without the current system of categorisation and completely miss its potential, the ways categories are organised reflect the type of structure the people who contribute to Wikimedia Commons prefer to work, ignoring this already structured system does a disservice to all of us and to the actual potential structured data on Wikimedia Commons has.
I can’t edit a “Caption” using the “Mobile view”.
These are all things a bot can read and ascribe properties to, why should we do all of this manually?
Also let’s use “Captions” as an example, while editing using the “Mobile view” mode I can’t edit captions. But let’s use a random file 📁 to illustrate how shortcomings with “Captions” could be solved by using already existing “Descriptions”, let's look at File:Oligotricha striata exuvia2.jpg where no caption is noted, meanwhile the description “exuvia of pupa of Oligotricha striata from Southwest-Germany between the towns Rottweil and Tuttlingen at 700 m.o.s at 2014-06-04 out of garden pont” from this a bot could add properties like “Oligotricha striata”, “Photographs taken in Southwest-Germany”, “Photographs taken in June 2014”, and “Self-published photographs”. I actually have a system of how existing structures could be used to properly organise data but as I don't have that much time I'll draft it later. Also as Wikidata only has 56,238,701 pages (53,846,977 content pages) Vs. Wikimedia Commons’ 69,674,025 pages (51,041,630 content pages & 51,622,895 uploaded files) it's clear that while Wikidata may be “the sum of all other Wikimedia website” the fact that Wikimedia Commons has no notability standards means that there are a lot of subjects on Wikimedia Commons than in all other Wikimedia Commons combined. Now forcing everyone to basically re-invent the wheel, I don't think that Wikimedia Commons mirroring Wikidata is a bad idea, I just think that there are better ways to implement Wikidata’esque forms of structure at the “Category:” level rather than at the “File:” level. As I’m really busy now I’ll write a concept in a follow up comment. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 20:12, 11 January 2019 (UTC)
Now let me try to illustrate how existing Wikimedia Commons categories could be better used to structure data than only individual files ever could. Now let me illustrate how we could implement Wikidata’esque organisation with a fictional cash coin from a fictional Vietnamese Emperor. Let’s say that there is a category called “An Hưng Thông Bảo” (安興通寶) which is a subcategory of “An Hưng Emperor”, “Coins of the Nguyễn Dynasty”, and “Coins of French Indochina”. Now any file in the category “An Hưng Thông Bảo” would automatically be given the properties “An Hưng Emperor”, “Coins of the Nguyễn Dynasty”, and “Coins of French Indochina” after their master-categories, now let’s say that every property is also a family of properties, as a fictional property “Coins” is “P641” and then “Coins of Vietnam” is “P641.5849” and “Coins of French Vietnam” is “P641.99586”, now these properties are non-editable when included in a category in the same way that all pages that use a certain license are categorised in certain maintenance categories. Properties could then be manually added if necessary, let’s say that there is an image of an exposé in Paris where the An Hưng Emperor is present in the audience alongside other notable people, rather than adding the category “An Hưng Emperor” a property or tag indicating that he is present would suffice.
So how would these properties differ from contemporary categories? Well, they would serve very similarly to “tags” on other image-based websites, a person can click on a property and then introduce filters by searching certain subproperties or excluding certain subproperties. “Captions” would also be more fit for categories.
I personally think that the structuring of data on Wikimedia Commons should probably work with the infrastructure already created by the community, much like how file descriptions can be helpful for bots. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 22:52, 11 January 2019 (UTC)

Don't think that it will be possible to collect structured data in such an unstructured way. The wiki way - we define the content, the rules and the tools in iterated and intermingled community processes - might not work here. Structured data (as it is now) for me is presenting a box without warning, without guidance, without concept, without transition strategy, without use cases, without purpose. Three or four years ago they told me that structured data will solve the bottleneck of categorization, now it seems that instead of easing some pain, structured data will add more pain by expecting community to enter descriptions twice. This will not work for the >50M Media we already have. I have disabled the box, like others. Full ACK to LX above. best --Herzi Pinki (обговорення) 17:56, 11 January 2019 (UTC)

Captions is only the first feature release for structure data - putting a wikitext file description into wikibase. I understand how captions may seem out of place when they're all alone, but there's some infrastructure behind them that had to go out first before we can add anything else. Within a month comes the first statement support, starting to shape out the structure of the metadata, with more to follow after that. Additionally, with further structure support comes tooling to help convert at least half of the file here without having to do everything manually (without touching the current summary/licensing/category system!). The release cycles for structured data are going to take a full calendar year to get everything out, and doing so without overwhelming everyone and everything. Keegan (WMF) (обговорення) 18:36, 11 January 2019 (UTC)
I've ignored the "enter caption" thingy for weeks as seriously bad idea, after all there are multilingual descriptions for all media, and I know how to add or edit those. Then enwiki started its odd WP:SHORTDESC crap (40 characters) with an intention to overrule Wikidata descriptions. Now commons gets 255 character captions overruling its established and working descriptions, for a total of four thingies (worst case) claiming to describe an item: d: + SHORTDESC + caption + {{information}}.
I tested it on a picture found in LinkedIn, File:ArtAndFeminism 2017 Livrustkammaren 06.jpg, it now has a German caption (maybe, that's what I tried), an English description, and a Swedish description. That can't be as it should be, the German caption should automatically populate the missing German description, and the plain text (no fancy markup, even no Interwiki) English description is perfectly suited as English caption.:-( 84.46.53.126 17:48, 30 January 2019 (UTC)

Proposal to remove captions feature[ред.]

The captions feature is not ready for 'live' rollout across the entire Commons project. There is no opt out, there is no way of using the API to batch create captions, i.e. for GLAM sources where an equivalent to captions may already exist. The use case for captions has not been tested with the wider Commons community, in practice only an extremely tiny proportion of the files hosted on Commons will ever have captions. It remains unclear why having captions is worth the additional investment or distraction of volunteer time from adding meaningful multilingual descriptions. In the case of my own uploads of several million GLAM related photographs, not only would duplicating captions from the description data be pointless, it would probably result in less than meaningful clipped titles. From the explanations and discussions so far, the captions are useful for Wikidata, but a messy and poorly implemented feature for Wikimedia Commons that is more likely to confuse rather than add specific value to this project. If Wikidata wants to have captions, then let that be a plugin for Wikidata-ists, rather than forcing every Commons viewer and contributor to see this on every image page.

It is proposed that this feature is removed until there is a supermajority consensus vote on the Wikimedia Commons Proposals noticeboard to implement it. -- (обговорення) 19:29, 11 January 2019 (UTC)

  • Symbol support vote.svg За As proposer. -- (обговорення) 19:29, 11 January 2019 (UTC)
  • Pictogram voting comment.svg Коментар I think captions feature is good for two reasons. Some images should carry some sort of accompanying text to briefly explain the subject and context. Take an image of Donald Trump. He's US president, a subject that would be interesting for people from all over the world. If each most popular writing scripts (latin, cyrillic, chinese, arabic, Devanagari, japanese, korean, etc. if by languages much more, EU alone has 20+) were to have one description, the description field ends up with a large chunk of text, most of which is foreign to any reader. With the new captions, it automatically displays the one the reader uses. The second benefit is that this short accompanying text becomes structured data that can be retrieved by machines. Perhaps what it needs is more customisation, like letting users switch on/off.--Roy17 (обговорення) 19:48, 11 January 2019 (UTC)
    • On "it automatically displays the one the reader uses", there is no magic solution. I'm currently shown 4 languages and these are not the 4 languages I'm most likely to understand. The pre-existing language select feature does pretty much the same. Nemo 19:56, 11 January 2019 (UTC)
  • Symbol support vote.svg За. Instead of offering a boon to vandals (IP included), developers should seek smart multilingual solutions (along the lines of my experimental {{3b}} template intended for descriptions). Incnis Mrsi (обговорення) 20:05, 11 January 2019 (UTC)
    • This is an odd critique - nearly all aspects of wikis by their very nature are "boon to vandals." This doesn't seem logical. -- Fuzheado (обговорення) 20:14, 11 January 2019 (UTC)
      @Fuzheado: of course we spend resources fending off vandals and other disruptive users who use various gadgets against Commons. But there is a large crowd of Commoners qualified to rollback mess with categories or revert an abusive {{db}}. Not so for a vandal adding captions, for example, nominally in Sanskrit or Albanian. Incnis Mrsi (обговорення) 20:46, 11 January 2019 (UTC)
  • Symbol oppose vote.svg Проти Another example of our proud tradition of immediately shitting on improvements to Mediawiki software. Maybe we try something different this time. Gamaliel (обговорення) 20:10, 11 January 2019 (UTC)
    • It is perfectly normal to expect a proper consensus process to be followed for significant project wide changes, not "shitting" on anything, but having reasonable respect for the unpaid volunteer community. No such consensus has been established before rolling out this change, in fact there has been hardly any meaningful engagement with the community to explain what this would look like, or the burden it introduces for all future work on this project. Actually, looking at discussion, nobody has even tried to work out how much applying captions this way in addition to the current way images are described will cost in unpaid volunteer effort. -- (обговорення) 20:32, 11 January 2019 (UTC)
  • Symbol oppose vote.svg Проти removing the feature. As stated by Roy17, this is the first step to the long overdue development of multilingual structured metadata and has been publicly discussed and proposed for many months at Commons:Structured_data. New things can be jarring, but this can peacefully co-exist and thrive alongside the existing norms. Nothing in the proposal identifies anything that would qualify as disruptive and functions like API access are in the pipeline. -- Fuzheado (обговорення) 20:14, 11 January 2019 (UTC)
  • Pictogram voting comment.svg Коментар @Keegan (WMF), : I can't support Fæ's proposal because "supermajority" is not defined and I don't think every new feature requires having a vote, but I do think the captions feature should be disabled for now. At the very least, there should be an option (without hacks) to disable it. The issue with huge boxes appearing needs to be fixed/made collapsible. phab:T213571 needs to be fixed. A clear plan on how this works together with descriptions needs to be presented. Realistic use cases need to be presented. - Alexis Jazz ping plz 20:20, 11 January 2019 (UTC)
    • On Wikimedia projects a supermajority vote is always a default of 60%. This is the norm for RFCs where significant changes to policy are involved. -- (обговорення) 20:28, 11 January 2019 (UTC)
  • Symbol support vote.svg За per above. Sneeuwschaap (обговорення) 20:32, 11 January 2019 (UTC)
  • Symbol oppose vote.svg Проти removal for now. This could be a potentially great way to expand the multilingual nature of Commons and make things work better with Wikidata. Let's revisit this in a month or two to see how rollout is fixed or improved on. Abzeronow (обговорення) 20:41, 11 January 2019 (UTC)
  • Symbol oppose vote.svg Проти If you don't like it then it's simple enough to hide it on file pages using a few lines of css [1]. Mike Peel (обговорення) 20:46, 11 January 2019 (UTC)
    • Let Mike Peel explain how to suppress this kind of edits in the watchlist… and yes, perhaps he could invent a solution making them invisible, but these edits likely will eat from my limit of events, clutter the browser’s memory and slow updates down, and will certainly interfere with such functions as rollback anyway. Incnis Mrsi (обговорення) 20:59, 11 January 2019 (UTC)
      • Have you asked the developers to do that by filing it on phabricator or elsewhere yet? Presumably it needs another option adding to the watchlist filtering. Mike Peel (обговорення) 21:10, 11 January 2019 (UTC)
    • CSS kludges aren't attractive for users not logging in (such as Be..anyone, who would support the proposal, while still telling you that supermajority  was never a thing on c: d: de: en: m: mw: in 2005…2016, unlike superprotect.:tongue:) –84.46.53.198 18:23, 5 February 2019 (UTC)
  • Symbol oppose vote.svg Проти A first and important step for Structured Commons. Let's try and help to improve it. Raymond 20:50, 11 January 2019 (UTC)
  • Symbol oppose vote.svg Проти per Gamaliel, Abzeronow and Raymond. Strakhov (обговорення) 20:55, 11 January 2019 (UTC)
  • Weak Symbol oppose vote.svg Проти, I can't say that I like the "Captions" feature, in fact I very much hate them as I have mistaken them for "File descriptions" a couple of times and after a file is uploaded I can't edit them using the mobile editing interface (which is bullocks!!!), but there is a lot of potential for them, and while I found the "feature" rather useless on Wikidata, "Captions" could be really helpful if they were extended to other pages on Wikimedia Commons beyond just files as they would be really helpful for categories. I really don't like them, in fact I personally hate them, but they do have potential. I would say that they might confuse uploaders and could seem to make the whole upload process more complicated for novice users and as us experienced users can't understand their exact usefulness I suggest that the MediaWiki Upload Wizard should explain what they do in the tutorial and give out more information on how to properly use them and what to fill in. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 21:20, 11 January 2019 (UTC)
  • Symbol support vote.svg За --A.Savin 21:37, 11 January 2019 (UTC)
    • you do need some kind of explanation, justification. A mere “vote” isn’t a useful contribution to the discussion. Wittylama (обговорення) 21:46, 11 January 2019 (UTC)
      • You do not get to censor people from voting here, all contributors are welcome to vote regardless of whether they want to add comments. -- (обговорення) 22:24, 11 January 2019 (UTC)
  • Pictogram voting comment.svg Коментар We’re happy to see robust discussion around structured captions, and we'll keep working to improve and build new features for structured data. We're investigating the option to show/hide for all users so individuals don't have to mess with their own css (although you CAN do that as discussed below), and we are considering other design fixes based on your feedback. Additionally, for those interested, we've got things working with adding captions via an API. Here's some initial documentation and we'll get some additional info up on mediawiki.org next week. Thanks! RIsler (WMF) (обговорення) 21:39, 11 January 2019 (UTC)
  • Symbol oppose vote.svg Проти As described by others above, this be feature is not a surprise or an insignificant change. It is highly publicised and a first “live” step in a major revamp of what Commons can do when combined with/supported by the power of Wikidata. Doubtless there will be bugs or unforeseen issues, however, it is hardly Assuming Good Faith to propose the removal of a major new feature on a Friday evening, shortly after it was turned on, because you don’t think it will be of much use or have much traction within the community. Wittylama (обговорення) 21:46, 11 January 2019 (UTC)
    • What is a surprise is that "captions" is where the Structured Data team want to start. Compared to dates, authors or copyright release, "Captions" are not currently part of Commons and Structured Data was promoted as not introducing new content to Commons, but to abstract existing data into better formats. Forcing 60 million new entries that need to be created across all of Commons content is bizarre and unexpected. Such a major change should have had a proper proposal to gain the community's consensus, not discussions on technical subpages that nobody follows, or technical posts that anyone not already involved will skip over; you know, because unpaid volunteer time is an ever more scarce commodity around here. This change should be reverted and go through a proposal when it has been properly tested and the impact understood. -- (обговорення) 22:19, 11 January 2019 (UTC)
      • There is nothing in the software requiring captions for a file. A caption is completely optional, as far as development is concerned. Keegan (WMF) (обговорення) 22:32, 11 January 2019 (UTC)
        • @Keegan (WMF): is anti-vandalism work on the captions also “optional”? Do you authorize us to ignore injection of trash into them? Incnis Mrsi (обговорення) 06:48, 12 January 2019 (UTC)
          • I hereby authorise you, and any other editor, to ignore captions, or indeed any other part of Wikimedia Commons. In fact, not doing so has never been compulsory. I thought everyone knew that. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 23:10, 12 January 2019 (UTC)
            You should be more protective with scarce resources such as "admin time", not everybody is free to ignore vandalism, spam fighters are not, by definition. –84.46.53.251 14:17, 17 February 2019 (UTC)
  • Symbol oppose vote.svg Проти, Captions are already adding value by being easily machine readable, one example is that they could already be used to improve accessibility for users with screen readers. Also there is an API that allows for editing of Captions so batch editing is possible. Abbe98 (обговорення) 22:15, 11 January 2019 (UTC)
    • Standard information templates are already machine readable, if anyone wanted to sort them out. The API changes have literally just been tacked on and at the time of starting this vote were in read only mode, so nobody has used these yet, more evidence that this was rolled out without understanding what the issues were. -- (обговорення) 22:19, 11 January 2019 (UTC)
      • It wasn't as easy as just calling wbgetentities. The Caption editing feature itself has been using the wbsetlabel API action since it was deployed as far as I know and the wbgetentities was there 12 hours ago when I first used it. The Commons community was invited to contribute with feedback very early on and this feature should not have came as a surprise. Abbe98 (обговорення) 22:49, 11 January 2019 (UTC)
  • Symbol oppose vote.svg Проти after all these years we are finally taking the first steps to deploy structured data on Commons and now you want to sabotage this effort? The grumpy old guys can just hide it in their Monobook css. Multichill (talk) 22:41, 11 January 2019 (UTC)
    • And not a hint of irony in this ad hom demeaning attack. Try to focus on the issue rather the people. -- (обговорення) 23:12, 11 January 2019 (UTC)
    • @Multichill: am I grumpy and old because I don't want to scroll through two pages of structured data captions on every single file page? I don't oppose the idea, but it must be properly tested before rolling it out. And as Roy17 pointed out below, redirects are getting captions too, which doesn't make any sense. Things like that should be fixed before implementation. - Alexis Jazz ping plz 23:22, 11 January 2019 (UTC)
      • i am grumpy and old, and object to the pattern of disabling any change to UI. some stoicism is called for. the perpetual whinging against VE, mediaviewer, timeless, wikidata, etc, etc... would be amusing if it weren't a dead weight against UX design. no wonder the devs do not want to engage with the kindergarten, Slowking4 § Sander.v.Ginkel's revenge 03:41, 12 January 2019 (UTC)
        • The Media Viewer – yes, a purely UI question. Not entirely so for the Visual Editor, as if—for example—some specific wiki code syntax became persistently mangled by it, then all users should be advised against that syntax. is not much about UI – it creates some new space. Who must look for it, Wikidatans will, perhaps? If we, experienced Commons users, eventually desert the corporation for some rival sites, then “devs” will not save Wikimedia with all their cool kludges. Incnis Mrsi (обговорення) 07:07, 12 January 2019 (UTC)
        • While it would be cheap and easy to suggest that kindergarten is where people are still struggling with basic literacy concepts, such as letter case, this ad hominem reference to a kindergarten does echo my feelings on the matter. Repeatedly we see how the community that is actually creating the content that has put some of the WMF websites among the most visited worldwide has its prefered workflows hindered by WMF employee’s pet projects, which often need to be either dismantled or more or less quietly set aside — where’s the responsible adults here and who are the whiny brats? -- Tuválkin 11:55, 14 January 2019 (UTC)
          • i do sympathize with the knowledge workers being besieged by thoughtless coders, but this is not a pet project; they are not toying with you. you cannot cast you UI in stone; you cannot improve it without trying new things. the constant refrain of "turn it off" is not helpful, or healthy. Slowking4 § Sander.v.Ginkel's revenge 01:20, 15 January 2019 (UTC)
  • Symbol oppose vote.svg Проти Impossible to say better than Raymond and Multichill did. Christian Ferrer (talk) 22:48, 11 January 2019 (UTC)
  • Pictogram voting comment.svg Коментар @Keegan (WMF), RIsler (WMF): There is one problem though. Captions should be turned off for redirects. Or a new bot should be developed to blank any captions added to redirects. See File:Swatow 20120713 1.jpg.--Roy17 (обговорення) 23:11, 11 January 2019 (UTC)
  • Pictogram voting comment.svg Коментар The motivation of caption feature is confusing, but from previous discussions it seems that it's intended an alternative to the filename. If we were designing Commons from scratch, an interesting design would be to give each file page a unique number (say an integer, like Flickr uses) which would be used when linking to the page, and then the multilingual captions would be available so that one could be displayed at the top of the page as the heading. This would be really convenient, since captions would be a) multilingual b) could be changed at any time without breaking incoming links. However, with the design presented, we still have filenames, and still have the inconvenient file renaming process. Now we also have captions competing with filenames as yet another way of describing the image. We also have a very poor user interface design, where the box for entering caption data for some reason has been given a lot of screen space, even for anonymous users who probably just want to see the image description, not enter a caption themselves. --ghouston (обговорення) 23:12, 11 January 2019 (UTC)
    • @Ghouston: actually, each file got a unique number because each MediaWiki page has a unique number. For files the pageid is combined with "M" to get a unique identifier like "M52611909", you can see it in this edit. Based on the ID you can get the json, rdf or the page. Multichill (talk) 23:58, 11 January 2019 (UTC)
      • That's the idea, although a link like [2] could be shortened obviously. I wonder if the entity numbers stay the same if the file is renamed. --ghouston (обговорення) 00:30, 12 January 2019 (UTC)
  • Symbol oppose vote.svg Проти We already have over 50 million files and we really need to do something to turn them into a well-organised collection. Caption is the first step, probably not a perfect one but a much needed one. Please do not kill this attempt to improve Commons at the very beginning — NickK (обговорення) 23:17, 11 January 2019 (UTC)
    • Risible. May a reasonable person believe that yet another cumbersome Wikidata thing may actually help with collections? It may have some other merits, such as helping reusers, but it’s a pure hindrance for tasks of Commons proper which has all devices necessarily to manage collections. Incnis Mrsi (обговорення) 06:48, 12 January 2019 (UTC)
  • Symbol oppose vote.svg Проти, this feature is really important to have, especially for smaller languages. Even if its not how everyone would like it to be displayed on Commons (the information is likely to be used in many more places). Maybe having a user preference option to display it in a different way would be helpful for people who dislike the current arrangement which they could define in an additional discussion? John Cummings (обговорення) 00:11, 12 January 2019 (UTC)
    • Will John_Cummings charge speakers of “smaller languages” for looking after respective activity and fighting vandalism? Are they willing to waste their precious time for it? Waiting for reports from outposts of “smaller languages” in the captions. Incnis Mrsi (обговорення) 06:48, 12 January 2019 (UTC)
  • Weak Symbol oppose vote.svg Проти I think the more sensible way forward is to allow users to turn of the feature, thus being able to build on the work already done without annoying so many users Oxyman (обговорення) 03:06, 12 January 2019 (UTC)
  • Symbol oppose vote.svg Проти I like it. --Jarekt (обговорення) 03:45, 12 January 2019 (UTC)
  • Weak Symbol support vote.svg За -- The bugs still need ironing our. The addition of the Captions field makes Upload Wizard even more cumbersome when uploading more than a single image: it's very easy to mistakenly add text meant for a description to a caption or vice versa, as I've already experienced. Plus, the caption box on file pages is garish and distracting: most users aren't going to interact with it, so it's an eyesore for them, and an eyesore plus an inconvenience to people that devote their time to curating files. --Animalparty (обговорення) 04:14, 12 January 2019 (UTC)
  • Symbol oppose vote.svg Проти I think this feature will help increase findability of commons files, both inside and outside the Wikimedia ecosystem of projects. I also think it is an important first step to increase accessibility of files for people with visual impairments and audio impairments. Until now only a tiny group has been adding captions using complicated templating. This enables multi-lingual captions in a much more obvious way. I hope it will draw more contributors to Commons, and maybe bring back people who used to contribute to the old captions projects. I haven't used it much yet, but I am quite happy to see how prominent the feature is while viewing files on Commons. I expected it to be much more unobtrusive. I am not scared of vandalism. In my experience the more eyes, the better, and this should theoretically draw more eyes. Jane023 (обговорення) 09:42, 12 January 2019 (UTC)
  • Symbol oppose vote.svg Проти Captions are annoying, but we have to get used to them. It's a step towards the right direction. Although for some time at the beginning they might be foldable, i.e. only a button should be visible. --jdx Re: 10:07, 12 January 2019 (UTC)
  • Symbol oppose vote.svg Проти I agree with most of what has been said against removal. Plus: the new system is not perfect? no suprise there and so what? it's new, it will be improved, give it some time. Maybe if in 6 months or 1 year, nothing changed, then we can reassess but let's give it a chance at least for now. Cdlt, VIGNERON (обговорення) 16:10, 12 January 2019 (UTC)
  • Symbol oppose vote.svg Проти the feature is an important step towards Structured Data. Surely one can opt out by writing a common.js file. Rama (обговорення) 16:15, 12 January 2019 (UTC)
  • Pictogram voting comment.svg Коментар If you want to hide or collapse it, you can now do so using gadgets − see Commons:File_captions#How_can_I_mask_the_captions?. Jean-Fred (обговорення) 21:08, 12 January 2019 (UTC)
  • Symbol oppose vote.svg Проти This needs to be improved, as expected, but that means moving forwards, not backwards. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 23:05, 12 January 2019 (UTC)
  • Symbol support vote.svg За temporarily disabling the feature until the rest of Structured Data is live. It's just not realistic to expect Commons users to manually fill out several billion text fields without the rest of Structured Data, so having the feature at this point in time is rather pointless anyway. Jc86035 (обговорення) 08:43, 13 January 2019 (UTC)
    I honestly don’t understand this line of argument. Who said anything about expecting users to manually fill out billion text fields? That’s obviously not going to happen. Really, it was the same when Wikidata was launched, pretty much empty, with the promise "when the millions of items will be created, then interlanguage links will be easier to manage!" ; as such, Wikidata was then also at that point virtually "useless" − you could create items manually (which I did, because it was fun ^_^) but that was obviously never really going to make much of a difference. Then we figured out bots to do that job for us. The same can, should, and most certainnly will happen here. Jean-Fred (обговорення) 13:01, 13 January 2019 (UTC)
    "Who said anything", you ask. The new giant white box did, holding one third of my screen hostage to scream its desire that I (manually) "write a very short description". Are we talking about the same thing?
    The giant white box presumably being discussed in this section
    Nemo 14:29, 13 January 2019 (UTC)
  • The currently enabled version is clearly a net negative for Wikimedia Commons and just a way to scream for attention and make users give feedback on this project. Nobody could possibly think it useful to make all users see an empty box which takes one third of the screen and pushes away actual content, so I'd suppose users don't need to scream for it to be obvious. I do wonder if this willing torture of our users is going to last multiple days or even weeks: if so, it would be a symptom that whoever is in charge thinks of Wikimedia Commons as some kind of backend project that people don't need to use, is dead set on making the Wikimedia Commons' users' life miserable, and will do anything they can to avoid changing mind even on the most pointless "design" choices (see all the absurd things MediaViewer still does years later, just because we didn't push back strong enough to kill it when we could). If that's the case, then it would be a sign that the entire structured commons project is doomed, which would a pity given it's very important. If they can't even manage a reasonable deployment of such a minor function as empty multilingual description boxes (which just replicates what we already have with a slightly different technology), one can't help worrying what's going to happen with the bigger parts of the project. Nemo 11:55, 13 January 2019 (UTC)
    • Two days later, the empty blockade box is still there, obstructing the users' work and usage of Wikimedia Commons. This is not promising. If it's not fixed by Friday, I guess we should start considering a more specific proposal, i.e. the hiding of all such experimental HTML via site-wide CSS until the thing is fixed. Nemo 15:36, 15 January 2019 (UTC)
  • Pictogram voting comment.svg Коментар The proposal does not specify what “Remove” means in this context (could be hide on the front-end, undeploy on the backend, or still something else) − as such, I don’t believe this poll will be very actionable. Jean-Fred (обговорення) 13:09, 13 January 2019 (UTC)
    • Well that's nonsense. It's perfectly actionable, as remove has only one meaning in the context of unwanted recent additions to a public wikiproject. Take the thing out by the root, burn it, and spread the ashes around. That's what every support vote is supporting and every oppose vote is opposing. — LlywelynII 18:45, 2 February 2019 (UTC)
  • Symbol oppose vote.svg Проти As others have said, we need to make progress on this front, and in my opinion this is not by removing things that are not perfect. We have to start the whole Structured Data somewhere. Now, if the frontend part of things needs to be changed (smaller font, collapsed by default…), I’m sure that the WMF would be more than willing to look into it, and lots of it we can also implement locally in the meantime − a few lines of code in the common CSS? Enabling the Collapse-Captions gadget by default for all users? If a consensus is reached for any such things, this can be implemented really esaily. Jean-Fred (обговорення) 13:09, 13 January 2019 (UTC)
  • Symbol oppose vote.svg Проти not because I am any great fan of Wikidata (I'm not) but it does no harm to English-speakers and it may help users in minority languages. There are improvements to be made e.g. moving captions and other structured data when it comes along after the file summary information, it needed the css hack to make it hideable. The look I doubt anything can be done about as it's all web 2.0 & OOUI. Nthep (обговорення) 13:40, 13 January 2019 (UTC)
  • This is a symbolic support, this isn't passing but for the record. — regards, Revi 13:47, 13 January 2019 (UTC)
  • Symbol oppose vote.svg Проти --ChristianSW (обговорення) 17:01, 13 January 2019 (UTC)
  • Symbol support vote.svg За -- obviously not thought through. Temporarily disable the feature or make it non-mandatory at least. Otherwise I will end up, mistakenly of course, typing crap into the required "Captions"- or the "Description"-field whenever uploading something. Alexpl (обговорення)
  • Symbol support vote.svg За, per nom and all preceding discussions. -- Tuválkin 11:55, 14 January 2019 (UTC)
  • Symbol oppose vote.svg Проти now that the gadgets are available. I would have supported without the gadgets.   — Jeff G. please ping or talk to me 10:39, 16 January 2019 (UTC)
  • Symbol support vote.svg За Obtrusive, disintegrative, not very promising. Until recently, the description was contained at two places: in the file name and in the Description field of the Information template. To add a third place, without any connection with the current description system, causes only chaos and disruption. --ŠJů (обговорення) 22:36, 17 January 2019 (UTC)
  • Strong Symbol support vote.svg За Late to the party, but since I'm here... There's nothing the "captions" feature does except duplicate the information that should already be in the title and description fields. If Wikidata somehow needed more or less information than what those already provided, edit them. If there was some problem with bots understanding or using the description data, make better bots or handle the formatting on the server side. Disabling the current eyesore should be far more intuitive than personal css coding. Getting rid of it altogether is far more helpful than making everyone go back through everything we have, creating "y'know, descriptions, but shorter and with worse formatting". — LlywelynII 18:36, 2 February 2019 (UTC)
  • Symbol oppose vote.svg Проти But it should be easy to collapse the box and empty fields shouldn't be shown.--Pere prlpz (обговорення) 21:42, 7 February 2019 (UTC)

disable captions on redirects[ред.]

special:diff/334447812 Captions on redirects should be redundant, innit? It'd be best to disable it on redirects. If this is not fixable in a short while, I think we should come up with a new bot, to 1. remove any captions on redirects on the spot; 2. issue templated warnings to user talk pages; 3. report recurrent offenders.--Roy17 (обговорення) 23:48, 11 January 2019 (UTC)

Hello! Yes, we are aware of the issue and it should be fixed next week. You can follow this ticket for progress. Thanks! RIsler (WMF) (обговорення) 01:22, 12 January 2019 (UTC)
I tried to link both tasks on phab, but I'm now sure how to. @RIsler (WMF): can you (either as a team or alone) please care for the the proper maintenance on phabricator? --Herzi Pinki (обговорення) 02:13, 12 January 2019 (UTC)
Of course. I think there already phabricator ticket for it. --Jarekt (обговорення) 03:47, 12 January 2019 (UTC)

poor descriptions of files (Proposal for improvement)[ред.]

We could have better descriptions as we do have in many cases. If we have descriptions at all. My proposal to ease the task of entering captions to files (for the benefit of the WMF and the world), is: Add a copy button to the Upload-Wizard that allows to copy captions to descriptions and vice versa, on a single file level as well as for all files in a multifile upload. But respect individual changes after copy. Furthermore the upload wizard could create captions from descriptions automatically as the last step, if the caption is missing. Reduce any wiki-text to the readable result and fail deliberately in case of line-limit is exceeded or the text contains non-convertible wiki-text. In most cases this will work. You can add a maintenance category for human attention when the conversion fails. --Herzi Pinki (обговорення) 01:39, 12 January 2019 (UTC)

Lessons learned?[ред.]

Are any lessons going to be learned from the disruption that very poor design and poor engagement demonstrated in this forced rollout of the unrequested captions feature, or can we look forward to more of the same argument and beating down anyone with sarcastic derision by treating them as stupid "grumpy old men" who should be ignored or put in a care home?

I am genuinely concerned that the community will be split into Wikidata promoters that appear to want to revolutionize the way editing and reading of Commons works, and the long term Commons content creators that want to get on with content projects without having to learn to to use what could become an entirely different project. At the current time this feels like a repeat of the volunteer time sink Visual Editor disputes which tediously went on for bloody years and basically was split between those with project funding based on theoretical improvement, keen to show results, and the majority of volunteers that wanted a stable continued project. Thanks -- (обговорення) 12:02, 14 January 2019 (UTC)

I do some editing on the Wikidata site itself, but this attempt to integrate with Commons has problems in its current form (starting with the fact that it doesn't work as intended in my browser). It seems to copy the flaws of Template:LangSwitch in that there's no way to see all the language versions together to check on translation accuracy and so on (see Template talk:LangSwitch#Langswitch considered harmful (when used beyond its intended purpose) etc.)? AnonMoos (обговорення) 14:41, 14 January 2019 (UTC)
Someone has now added a "caption" to my image File:Vulva-handsign-Yoni-mudra.svg. I sure hope that's not the way it's supposed to work... AnonMoos (обговорення) 05:37, 16 January 2019 (UTC)
FULL ACK @:. --Herzi Pinki (обговорення) 01:27, 15 January 2019 (UTC)
At least it is clear from this poll that the majority of volunteers think differently ;-) Braveheart (обговорення) 10:35, 16 January 2019 (UTC)
I think Fæ has a point here about how the feature was implemented, rather then the merits or otherwise of the feature. Oxyman (обговорення) 22:43, 17 January 2019 (UTC)
Braveheart, think different about the short-term solutions, maybe. I certainly don't see a "majority of volunteers" saying that no lessons can be learnt. Nemo 13:01, 20 January 2019 (UTC)
certainly, there should be some training on how to implement open source UX design changes in a open source community. but this is a soft human resource management practice, so is too hard for the average coder. we should expect the lesson to remain unlearned. just as the "constructive feedback in open source communities" lesson is unlearned. Slowking4 § Sander.v.Ginkel's revenge 17:12, 24 January 2019 (UTC)

The giant white box is still unfixed in that it hampers usage of file descriptions, ruining the Commons life of most people (especially unregistered users who cannot do anything about it). I guess we need to start considering how to remove/hide/move it by community consensus. Nemo 08:38, 26 January 2019 (UTC)


I hope whoever implemented these captions anticipated things such as Special:Contributions/Dudewing... AnonMoos (обговорення) 05:07, 1 February 2019 (UTC)

I think the project already knows about and deals with vandalism, but yes of course the giant empty "comment here" space on every image is just asking for a huge uptick in stuff like this. If it weren't, it would be able to use the existing titles and description data. — LlywelynII 18:54, 2 February 2019 (UTC)

Well nobody can deny it encourages casual visitors to contribute. 70.45.40.207 (обговорення · внесок · Журнал перейменувань · журнал блокувань · завантаження · Журнал фільтра редагуваньblock user.--BevinKacon (обговорення) 11:35, 3 February 2019 (UTC)

Brexit[ред.]

There's less than two months to the date that the UK is due to leave the EU. That date could easily change but when the actual withdrawal happens, it will affect Commons. For instance, most of the files in Category:Maps of the European Union will become inaccurate overnight.

I suggest that we make more preparations for this than the British government and mark any content that will need updates in advance. Then when (or if) the actual withdrawal happens, then we will know which files need updating or replacing. A bot could handle any category changes.--Nilfanion (обговорення) 13:52, 2 February 2019 (UTC)

  • They won't become "inaccurate", they'll become historical. That said, yes, someone should have a bunch of maps ready to show the new situation. - Jmabel ! talk 17:52, 2 February 2019 (UTC)
  • While that may appear true, many of the maps will be updated by an overwrite instead of an upload to a new location. That's because the subject doesn't really care about boundary and this is reflected in a simple undated file name, with the description and actual usage on WP (and elsewhere) just indicating it shows the EU [as it is right now]. The old version will become historical, but has very limited educational value. File:European Union Sudan Locator.svg would be an example of this. If the files instead showed the EU at a fixed date, with a description and file name backing that up, then yes it would become historical. Providing that level of detail isn't really necessary.
With regards to identifying and marking the files - maybe create a template and category to track?--Nilfanion (обговорення) 18:54, 2 February 2019 (UTC)
Screw maps, what happens to copyright if they leave? Nothing? Or are strange things going to happen. - Alexis Jazz ping plz 21:44, 2 February 2019 (UTC)
I don't think there will be any changes in the short term that will affect Commons. There's a draft statutory instrument to amend the relevant law, and it's almost entirely changing the territorial scope of things. --bjh21 (обговорення) 00:06, 3 February 2019 (UTC)
It is conceivable that the “sweat-of-the-brow doctrine” (with implications for PD-Art and possibly TOO) could be reinstated; IIRC it was struck down in a case a few years ago to comply with an EU court ruling. Someone might just reopen the question post-Brexit.—Odysseus1479 (talk) 21:12, 3 February 2019 (UTC)
PD-Art is something that Commons has decided on, irrespective of local laws, so changes in local laws won't have an effect on PD-Art.--Prosfilaes (обговорення) 07:28, 5 February 2019 (UTC)
IIRC "sweat of the brow" affects commons, unless the servers are moved to another country: So coins no (sweaty 3D thingies needing a lot of moving around by the photographer to catch a nice perspective), photos of PD paintings yes (mere scanning of silly 2D cruft), and never try Germany, where everything requires sweat (that's related to our singing and marching and other ugly habits.) –84.46.52.2 14:15, 11 February 2019 (UTC)

Structured data licence.[ред.]

What licence(s) cover the new structured data being rolled out across Wikimedia Commons?

The Commons homepage states: "Text is available under the Creative Commons Attribution-ShareAlike License; additional terms may apply."

My understanding is that the data will be replicated in some form on Wikidata which states: "All structured data from the main, property and lexeme namespaces is available under the Creative Commons CC0 License; text in the other namespaces is available under the Creative Commons Attribution-ShareAlike License; additional terms may apply."

One specific test case I'm interested in is as follows: A machine learning algorithm is trained using images from the Commons licensed under various permitted schemes and their associated structured data. Does ShareAlike prevent the resultant software from being proprietary?

--Edit-pi (обговорення) 21:17, 5 February 2019 (UTC)

In that specific test case, ask your lawyer, and know that whatever they say can't stop you from being sued. The legal issues of machine learning are far from being beaten out.--Prosfilaes (обговорення) 06:00, 6 February 2019 (UTC)
The structured data portion of Commons will be CC0 by necessity to live and work in the Wikidata ecosphere. The footer at the bottom of pages on Commons is in the process of being modified for these new licensing obligations (links available at my Village Pump/Copyrights post), and there are designs available for review for notifying editors about CC0 in the structured data space.
As for your specific use-case question, I agree with Prosfilaes that you should consult an attorney. Keegan (WMF) (обговорення) 18:41, 7 February 2019 (UTC)
@Keegan (WMF):@Prosfilaes: Thank you for your replies.
I am uneasy about the blanket adoption of CC0 for structured data on the Commons as my cynical suspicion is that doing so leaves the time and effort of volunteers open to commercial exploitation, specifically with regards to data trained machine learning algorithms. Of course the optimistic view would be that doing so makes it easier for open-source alternatives to emerge so one can but hope...
If existing description text is CC-BY-SA does that mean that it cannot be copy-pasted as a caption?
--Edit-pi (обговорення) 10:04, 11 February 2019 (UTC)
If existing description text is CC-BY-SA, it can not be taken as CC0. Note that much description text is clearly subcopyrightable, and much of the rest is on the line.
The CC-BY-SA specifically permits commercial exploitation, and someone using CC-BY-SA photos is likely safe if they keep the results in house. If the machine learning application is distributed, then it might have to be under a license compatible with the CC-BY-SA. It doesn't really matter if the CC0 or CC-BY-SA is used in claiming a photo is of a white-tailed antelope squirrel; that's a fact and not copyrightable.
The copyright problem comes from the fact that if you have just one photo of a certain creature, a machine learning program that recognizes that creature can be driven in reverse to basically produce that photo; the same is true, but in a more complex way, if you have more photos. The rules are unclear, but I really hope they don't stop anyone from producing a program that can properly tell what species my photo is of.--Prosfilaes (обговорення) 14:07, 11 February 2019 (UTC)

February 06[ред.]

Cat-a-lot doesn't work?[ред.]

Cat-a-lot doesn't work today? When I click the "Cat-a-lot" link, it does nothing. --ŠJů (обговорення) 00:18, 7 February 2019 (UTC)

I recently noticed the same problem. --Animalparty (обговорення) 00:30, 7 February 2019 (UTC)

Zhuyifei1999 reported as ✓ Fixed 16:31, 7 February 2019.

License reviewers and admins help is needed ASAP[ред.]

Yes check.svg Вирішено

Many of photos in Category:Farsnews review needed will be lost soon. Please help reviewing them using Google cache (http://cachedview.com/), Bing cache, or Internet Archive.

Priority is with provincial files whose url does NOT start with www. For example see the url of File:Alexander's Prison 13960103 01.jpg which is http://yazd.farsnews.com/multimedia/photo/13960103000824.

Pinging Persian-speaking admins @Mhhossein, Mardetanha, Ebrahim: and license reviewres @Mehdi, Meisam, Hanooz: as well as some active license reviewers @Leoboudv, GRuban, Gone Postal, Roy17, Christian Ferrer:. Your help is greatly appreciated. 4nn1l2 (обговорення) 10:06, 7 February 2019 (UTC)

Thanks for your help. As the uploader I can't help here. Hanooz 10:38, 7 February 2019 (UTC)
REWRITUN UR URLZ
  • Image. - Alexis Jazz ping plz 14:23, 7 February 2019 (UTC)
@4nn1l2: I haz averted crizis? - Alexis Jazz ping plz 14:35, 7 February 2019 (UTC)
@Alexis Jazz: Yes, you probably have. But what about File:Chama Ice Cave 13970604 19.jpg? 4nn1l2 (обговорення) 14:44, 7 February 2019 (UTC)
@4nn1l2: 26 images from http://fars.farsnews.com/multimedia/photo/13970604000852. I don't know. https://www.farsnews.com/photo/13970604000852 doesn't work, no Google cache, no Bing cache. - Alexis Jazz ping plz 15:22, 7 February 2019 (UTC)
  • Not all new URLs work. Anyways we should review all of them asap. Someone also has to move reviewed ones out once every few hours.--Roy17 (обговорення) 14:51, 7 February 2019 (UTC)
I can do that. - Alexis Jazz ping plz 15:26, 7 February 2019 (UTC)

Pinging @4nn1l2, Leoboudv, GRuban, Gone Postal Pinging @Roy17, Christian Ferrer, Animalparty YMMV - Alexis Jazz ping plz 17:08, 7 February 2019 (UTC)

Pinging @4nn1l2, Leoboudv, GRuban, Gone Postal Pinging @Roy17, Christian Ferrer, Animalparty please download the following:

This should allow you to review the 398 files in Category:Farsnews provincial files for which the live link appears to work review needed at some later point even if the links stop working. - Alexis Jazz ping plz 19:29, 7 February 2019 (UTC)

@Leoboudv: Commons:Village pump/Archive/2018/11#Flickr will not delete CC photos. Still, we should keep importing as users may delete photos themselves in order to be able to upload new ones.
I will take a look at Flickr reviewing. (by which I mean: fixing files so the bot can review them) - Alexis Jazz ping plz 20:02, 7 February 2019 (UTC)
@Alexis Jazz: Why don't you apply for license reviewer right? You are apparently knowledgeable enough. Strakhov (обговорення) 01:44, 8 February 2019 (UTC)
That's an understatement, if anything. You should see the last two tests Alexis gave the last two license reviewer candidates! Really, Alexis, I'd support you in a heartbeat. --GRuban (обговорення) 01:47, 8 February 2019 (UTC)
@Strakhov, GRuban: thank you. I was considering to apply again, but I applied half a year ago and was turned down not because of questions about my knowledge, but due to trust issues. Nothing has changed in that regard. - Alexis Jazz ping plz 02:04, 8 February 2019 (UTC)
I also support User:Alexis Jazz for license reviewer right. Please apply! 4nn1l2 (обговорення) 02:20, 8 February 2019 (UTC)
@Alexis Jazz. Well, as long as you don't review your own essays... Lol, I'm kidding. A cup of trust here too. Strakhov (обговорення) 02:31, 8 February 2019 (UTC)
You should apply again, Alexis Jazz. Opinions change. --Majora (обговорення) 04:38, 8 February 2019 (UTC)
@Strakhov: when things calm down a little, I plan to request undeletion of my essays. (I will make adjustments to the Everipedia essay though) Majora's comment almost pushed me to re-apply, but your comment about my essays makes it clear I really shouldn't. - Alexis Jazz ping plz 11:40, 8 February 2019 (UTC)
Looking at the LR debate out of curiosity (triggered by the image caption), it's no "vote" (by definition), 2 objections with reasons (ignoring one harmless confusion about "canvas" or not), 1 of 2 mitigated by "opinions change" a few lines above, this is commons, it cannot get better (by definition). –84.46.52.2 16:44, 11 February 2019 (UTC)
  • Pictogram voting info.svg Довідка Thanks everyone! Almost all the files were saved, except for one gallery containing 26 images: Category:Chama Ice Cave. I will try again a few days later for Bing and Google cache. If still unsuccessful, I will delete them (or nominate them for deletion). 4nn1l2 (обговорення) 13:05, 8 February 2019 (UTC)
@4nn1l2: best to go to DR. I had some ideas to try and find them (if they are still there), but I can't navigate the site very well because I don't understand the language. Besides, they are watermarked and have EXIF which can probably be matched to other (reviewed) photos from this photographer. It may be beyond COM:PRP to assume they don't originate from Farsnews. Hanooz would have had to insert the watermark and fake the EXIF..right.. And we have accepted self-reviewed files in the past from license reviewers who were unaware they were not supposed to self-review. In this case, if we can't verify the files another way, I would allow Hanooz to self-review them. - Alexis Jazz ping plz 13:57, 8 February 2019 (UTC)
Pinging @4nn1l2, Gone Postal, Roy17, GRuban http://pics.farsnews.com/?nn=13970604000852 !! - Alexis Jazz ping plz 14:06, 8 February 2019 (UTC)
✓ Виконано Alexis, I am highly tempted to draft you into being a license reviewer. By force. With an army of other License Reviewers bearing torches and pitchforks. --GRuban (обговорення) 17:47, 8 February 2019 (UTC)

Digitally manipulated photographs[ред.]

User:FOX 52 has uploaded a number of digitally manipulated photographs. Many of which are cropped out ground aircraft superimposed on sky. The following gallery are some examples.

en:Wikipedia:No original research states that "[i]t is not acceptable for an editor to use photo manipulation to distort the facts or position illustrated by an image." In at least one instance, people have been misled by a manipulated image. Considering that Commons have photos of these aircrafts in flight, do those digitally manipulated images realistically serve an educational purpose? -Mys_721tx (talk) 08:17, 8 February 2019 (UTC)

Added: template {{retouched}} and "other version" with orig. image visible. Vysotsky (обговорення) 09:04, 8 February 2019 (UTC)
As long as these images are marked as manipulated, I don't see a problem. --MB-one (обговорення) 10:18, 8 February 2019 (UTC)
@FOX 52 should mark such images as manipulated and attribute sources themselves, rather than fraudulently claiming "Власна робота" and illegally violating the copyrights of others. See also COM:AN/B#FOX 52.   — Jeff G. please ping or talk to me 10:29, 8 February 2019 (UTC)
Based on the file names, There are 86 files need to be checked for proper tagging. -Mys_721tx (talk) 13:54, 8 February 2019 (UTC)

Copyright fraud? - All image(s) that have been modified have been given their proper attributes, if any have any missing it's purely unintentional & can be rectified – And I don’t appreciate the accusation - FOX 52 (обговорення) 17:53, 8 February 2019 (UTC)

Cropping out background and replacing with sky is one thing; adding insignia of another country to an F-16 is something altogether different. We do NOT want to imply that this is an actual photograph of an Egyptian F-16, because it isn't. Even if it's not copyright fraud, it is not an accurate representation of what it claims to represent. Either the title and description need to be changed, or the image needs to be deleted. --GRuban (обговорення) 17:59, 8 February 2019 (UTC)
  • It would be nice if Fox saved the intermediate images with a transparent background, that way it would help identify them as manipulated, and users may prefer no background, which gets rendered as white in Wiki projects. RAN (обговорення) 21:17, 9 February 2019 (UTC)
  • I think if both the filename and descriptions clearly state they are modified images, then ok. Removing or altering a background is not too bad. However, I think changing the insignia on the planes to imply the plane belongs to another air force is a step way too far. That's getting into user-generated art and fantasy, and not compatible with our educational mission. So I think that change should be reverted or the photo deleted. -- Colin (обговорення) 21:58, 9 February 2019 (UTC)
  • I agree with Colin. - Jmabel ! talk 22:29, 9 February 2019 (UTC)
  • I think removing the background and making it transparent would be fine. (and quite nice, actually) Replacing the background with sky however, I'm not a big fan of that. There should be a footnote in the image to explain the background was swapped out. Alternatively, an image of some very cartoonish sky drawing could be used so nobody will be fooled. Replacing flags/insignias is not done. As depicted, that plane doesn't even exist. If a plane like it does exist in real life but there is no free picture available, a drawing of that plane could be made with those insignias. Simply photoshopping the "right" insignias on another plane, no. - Alexis Jazz ping plz 00:04, 10 February 2019 (UTC)
  • To me, altering the background is debatable. Removing the background to make the aircraft more presentable is not encyclopedic. But removing components from the aircraft is already too far. To assert that the altered picture is what the aircraft would look like is well into the original research territory. -Mys_721tx (talk) 00:27, 10 February 2019 (UTC)
  • Cutting out aircraft that are long out of service which there are limited photographs available is useful. But they should be on solid color background, not sky, as it misleads. File:Egyptian F-16 (modified).jpg is purely false and should be deleted. File:Bulgarian mig-29 (altered).jpg unless reference images are provided, should also be deleted as false.--BevinKacon (обговорення) 11:20, 10 February 2019 (UTC)
files uploaded with "remix" or "mod" in file name
This is a list of FOX 52's uploads with "remix" or "mod" in the file name. This list does not necessarily include every manipulated photo as files such as File:Chengdu J-10 - 殲-10.jpg will not be detected by the SQL query. There are actual in flight photos on Commons for most, if not all, fake ones. -Mys_721tx (talk) 18:54, 10 February 2019 (UTC)
  • It is really unfortunate that so much effort was put into this. Despite these being many many many hours of tedious editing, I agree with most above that the misleading files should be deleted. Rehman 14:08, 12 February 2019 (UTC)
How exactly dose an aircraft in the Sky misled the reader? Putting the aircraft in outer space upside down flown by a monkey is MISLEADING!!! - FOX 52 (обговорення) 19:28, 12 February 2019 (UTC)
@FOX 52: If you pretend you shot a good photo in the air while matching speed with one of the fastest jet fighters in the world today (or any aircraft, really), and it turns out you ripped off someone else's work on the ground, that's a pretty big deal. So is canvassing.   — Jeff G. please ping or talk to me 22:33, 12 February 2019 (UTC)
OK that really didn't answer the question, and share alikeIf you alter, transform, or build upon this work, you may distribute the resulting work in NOT ripping off someone's work. - FOX 52 (обговорення) 03:17, 13 February 2019 (UTC)
@FOX 52: Where's the source and attribution in this edit? Have you ever photographed an airplane while in another airplane? I haven't, but I haven't pretended to.   — Jeff G. please ping or talk to me 03:23, 13 February 2019 (UTC)
@Jeff G.:- You mean this file which was kindly corrected by Mys_721tx? out of roughly 1,500 files I've uploaded there's one file? (And that shows my history of trying to steal the work of other's?)- Assume good faith on your fellow editors Jeff - FOX 52 (обговорення) 05:03, 13 February 2019 (UTC)

┌─────────────────────────────────┘
@FOX 52: No, that's just the first I came across. How about the following ones?

Also, these with bad attribution?

Hmm? You also should be using internal links. In addition, you are responsible for every edit you make, not just the finished product, and you should explain the modifications you made with {{Retouched}} and mention your work at the source pages.   — Jeff G. please ping or talk to me 06:47, 13 February 2019 (UTC)

This was already discussed in Wikipedia:Wikipedia_talk:WikiProject_Aircraft/Archive_43#Photoshopped_Images,_Part_Deux. While I also clip backgrounds (mainly to remove people or busy backgrounds in aviation showrooms), I do not replace them to place the subject in fictional situations, which I think would not be educative. Removing the landing gear is off limits too, IMO.--Marc Lacoste (обговорення) 09:25, 13 February 2019 (UTC)
Quite. Once one has removed the landing gear etc., and placed the aircraft in a different attitude with a different background, portraying it in a totally different scenario than that in which it was photographed, it's not a photograph any more - it's an artist's impression of what the aircraft might look like in that invented scenario. If it's not very clearly described as such, with a proper, clear audit trail then it really is basically deceptive. Applying fictional liveries without such clarity is especially 'gob-smacking'. I'm disappointed, because I've known FOX as a good, helpful, capable graphist for a long time, but these examples overstep many lines and are really not acceptable like this. -- Begoon 09:43, 13 February 2019 (UTC)
@Jeff G.: Disappointing to see that you failed to mention that upon my uploading of those files under a blanket Upload Wizard page, I immediately applied the proper attributes seen in the history diffs: AC-47D - VH-60_Marine_One - Iranian_Air_Force_Grumman_F-14A - B-58 - AIM_9L_Sidewinder - Cessna_408_SkyCourier ...etc - So no ones work claimed by me. Cheers FOX 52 (обговорення) 16:40, 13 February 2019 (UTC)
@FOX 52: Can you please stop uploading others' work "under a blanket Upload Wizard page"?   — Jeff G. please ping or talk to me 22:52, 13 February 2019 (UTC)

Fantasy parliament diagrams for nationstates.net[ред.]

Slashme's excellent parliament diagram tool seems to have acquired a fanbase on NationStates. For a few weeks I've been puzzling over Shamar54's creation of fictional election results for Eraver, a mystery until I found Eraver on nationstates.net. Once you see one they're everywhere... Daskaiserreich's File:Andrews paldesia election.svg [5] and File:New Maranoa House of Represenatatives 2015.svg [6], Nenufman's collection of Amenuf [7] and Virlinia [8] elections...

Can we have a bot delete any parliamentdiagrams in Category:Election apportionment diagrams that are still unused a week after creation?

Slashme, there could be a business opportunity there for you ;-) Cabayi (обговорення) 15:12, 8 February 2019 (UTC)

  • I'm confused: so if someone creates a breakdown of (say) the Washington Territorial Legislature in 1885 and it isn't promptly used in an article it should be deleted by a bot? Why? - Jmabel ! talk 16:44, 8 February 2019 (UTC)
Jmabel, fair point. Personally i can't conceive of putting in the effort to create an election diagram and then not taking the small final step of including it in an article as an incontoversial simple addition. Can you think of a way of cleaning up? Without action they'll just accumulate - search for parliamentdiagram on forum.nationstates.net. Cabayi (обговорення) 09:30, 9 February 2019 (UTC)
I can imagine someone going through the history of some legislative body turning out diagrams without concerning themselves about any Wikipedia. Not that I'm against deleting fictional crap: just don't see it as clearcut enough for a bot. A bot could notify a human, but the human needs to make a decision. - Jmabel ! talk 17:47, 9 February 2019 (UTC)

User:B noticed this problem a while ago, and upon his suggestion, I've tried to make the user interface clearer about the fact that only diagrams that are for use on Wikimedia projects should be uploaded. I'm not sure how to check whether that's working, though. There are definitely lots of diagrams that should be deleted. Ultimately, it would be better if the diagrams could be created on the fly in the pages where they're used, ideally from Wikidata, but I don't have an idea how to do that. I support automatic deletion of unused diagrams without detailed descriptions. --Slashme (обговорення) 05:16, 11 February 2019 (UTC)

Commons is not a webhost; these fantasy diagrams are being made by editors who have no intention to contribute to Commons. Given the scope of the problem, I think speedy deletion of files and short blocks for the non-contributing editors (with the intention of that being frustrating enough for them to find a new webhost, while leaving open the possibility of productive contributions in the future) is the best way to go. I've seen several very similar usernames which indicates that some of these users may be using multiple accounts. Pi.1415926535 (обговорення) 05:54, 11 February 2019 (UTC)

Small edit[ред.]

Can an administrator add Category:Yardangs to today's Featured Picture (File:Monjes de la Pacana, Chile, 2016-02-07, DD 26.JPG)? It is resulted from erosion by wind. Thank you. RXerself (обговорення) 10:52, 9 February 2019 (UTC)

✓ Виконано (although I am not a geologist, nor an admin!) --Animalparty (обговорення) 06:07, 11 February 2019 (UTC)

Watercolour World[ред.]

Is anyone working on uploads from Watercolour World, a new initiative which styles itself "a digital database of all pre-1900 documentary watercolours in the western tradition"? Sample page are [9] and [10]. Note that the latter can be zoomed, the former cannot, and misleadingly claims to be "All Rights Reserved". Their press release says "The project already comprises around 80,000 images, many of which have been digitised for the first time by The Watercolour World." Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 13:38, 9 February 2019 (UTC)

@: Of interest? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 16:09, 13 February 2019 (UTC)
Possibly, though not right now. Have to think through handling at least some paintings classic copyfraud. Not sure those uploads should be on my (openly UK based) account.
Could make for an interesting experiment with an alternative workflow. -- (обговорення) 16:17, 13 February 2019 (UTC)

Removing "Check categories"[ред.]

I was preparing to remove {{Check categories}} which MedalSmeddle (talk · contribs · deleted contribs · logs · edit filter log · block user · block log) (Russavia) had indiscriminately added to +20.000 of his uploads for no apparent reason. Due to what seems to be a cat-a-lot bug, I accidentally categorized User talk:Uli Elch. There I found User talk:Uli Elch/Archives#"Checking categories".

I still think it was wrong to indiscriminately add {{Check categories}} to +20.000 files. If there is opposition to me removing {{Check categories}} from these files I will cease and undo what I did so far. Otherwise, I'll finish what I started. - Alexis Jazz ping plz 16:17, 9 February 2019 (UTC)

I didn't quite catch in what sense those 20k category additions are considered "indiscriminate". From that discussion I see that at least some users believe that "Every aircraft file should have categories for registration, type, operator, date and location". Presumably the same users may find it useful to have a way to find the files which don't. Are you saying you will remove {{Check categories}} from the files after checking that they actually have all those desired categories, or did you find some other criterion? Thanks, Nemo 16:53, 9 February 2019 (UTC)
Isn't that what Category:Aviation files (check needed) is for? Oxyman (обговорення) 17:03, 9 February 2019 (UTC)
@Nemo bis: do you see any aircraft on File:Battle of Britain "West Country" Class 34028 Eddystone (8489214275).jpg? Okay, there's a train, that's a mode of transport. Maybe File:Inaugural Stockholm - New York (7).jpg. Well I guess it was taken at an airport. File:In Tacloban, Philippines (10939193345).jpg maybe? There is something with wheels in the image, but it's not going anywhere. The people on File:In shadows of columns of St. Peters Square (2984988366).jpg are all sitting. No transportation whatsoever. All these files were tagged with {{Check categories}} years after Russavia uploaded them. The edit comment for all was "removing string of text from source which is resulting in erroneous attribution, as discussed on VP - Doing 4 replacements". They were removing Category:Files uploaded by Russavia and an "uploaded by" line. Fine, but that's no reason to insert {{Check categories}}. - Alexis Jazz ping plz 17:16, 9 February 2019 (UTC)
Two days have passed. If an uploader tagged their uploads with {{check categories}} at upload time without actually checking the categories themselves it would be bad practice, but whatever. If someone wants to dump thousands of files in some Category:Unidentified aircraft category, no problem. Indiscriminately dumping thousands of unrelated uploads in a general maintenance category years after upload? No. In a few hours, I will finish what I started. - Alexis Jazz ping plz 18:04, 11 February 2019 (UTC)

vertical bar problem[ред.]

When media is imported via video2commons etc, if | is included in the displayed text of a link, it would be replaced by {{!}}. This causes one problem, that if the source field is such a link, and a reviewer copies the link as the site parameter in {{licencereview}}, the resultant template will be malformed. (See also Template_talk:LicenseReview#malformation_due_to_template:!.) Should those tools substitute & #124; instead of {{!}}?--Roy17 (обговорення) 18:37, 9 February 2019 (UTC)

Wanted to point out that I modified the license reviewer script that I maintain to replace the instance of {{!}} with the vertical bar escape (& #124;) in both the source parameter and in the LR template once the LR is passed. The {{!}} template is a special use magic word that really shouldn't be used this way anyways. --Majora (обговорення) 19:24, 9 February 2019 (UTC)
JFTR, it's a magic word for years now, and it was always intended for cases, where &#124; wasn't good enough (note decimal notation, my netscape 2.02 was too stupid for hex. back in 2006). –84.46.52.2 17:44, 11 February 2019 (UTC)

File:Samuel Walker McCall circa 1920.jpg[ред.]

The image File:Samuel Walker McCall circa 1920.jpg was being used for the wrong person with the same name, I fixed them and then purged my cache to make sure I got them all, but it still lists being used in the Catalan wikipedia. Can someone take a look and see why? RAN (обговорення) 20:52, 9 February 2019 (UTC)

Seems cleared from Catalan to me. I went ahead and created a cropped version for a more formal appearance. --Animalparty (обговорення) 01:40, 10 February 2019 (UTC)
I added your version as the Wikidata image. RAN (обговорення) 17:41, 10 February 2019 (UTC)

February 10[ред.]

remove old file history[ред.]

I found some images contain not necessary detail information like GPS locations, I uploaded a new version which has removed these information, however I have no permission to remove the old one, how to remove the history version? -- Porsche613 (обговорення) 04:48, 10 February 2019 (UTC)

Only administrators can delete things or remove history from pages. I'm guessing you mean File:Dopod D600 CMCC Version with WM6.1 20130411 145351.jpg in which case I took care of it for you. --Majora (обговорення) 04:51, 10 February 2019 (UTC)
Yes that is. And File:8600GT_GPU.jpg, File:Dopod_D600_CMCC_Edition_20130409_150028.jpg, File:ULN2003A PDIP16.jpg, File:ULN2003 SOP16.jpg and File:Sony_Xperia_U_(ST25i)_front_side_20130321_103546.jpg(this also have 2 duplicate history version) have the same issues. -- Porsche613 (обговорення) 06:09, 10 February 2019 (UTC)
I believe I got it all Porsche613 but if not please let me know. --Majora (обговорення) 08:04, 10 February 2019 (UTC)
Got it, all clear. Many thanks Majora. -- Porsche613 (обговорення) 14:07, 10 February 2019 (UTC)

Parade royalty[ред.]

We seem to lack a category for the concept of "parade royalty", pretty common in the U.S. and probably to some extent elsewhere. We have some things that should be subcategories of that: Category:Seafair royalty, Category:Queens of the Tournament of Roses, Category:Carnival Queens. Some parade royalty (e.g. queens of the Tournament of Roses) are beauty contest winners but others (like this and this, the two that sent me looking for a category like this) certainly are not.

Complicating factors in creating such a category:

  • I'm not even sure "parade royalty" is the proper generic term, though its the one I've always used. Very often their duties extend to other civic activities besides their appearances in one or more parades.
  • What would the parent categories be?
    • As I said, some but not all are beauty contest winners.
    • Should this descend from Category:Royalty? That has subcat Category:Fictional royalty but that's for fictional figures like Snow White and Prince Charming, not for real people whose royal title is fictional.

Ideas would be appreciated. - Jmabel ! talk 05:45, 10 February 2019 (UTC)


The Lord Mayor of London has never been a "lord" in the sense of a peer of the realm, and similarly, no one thinks that the Rose Bowl queen is a real "queen" in the sense of a territorial sovereign, so I don't think such categorizations are useful. I don't know that there's always a parade, necessarily -- some of them are crowned at county fairs and such... AnonMoos (обговорення) 05:54, 10 February 2019 (UTC)
Again: I'm not talking specifically about beauty pageant winners, even though the concepts overlap. But there is a role in parades that is an identifiable thing, and we have a lot of pictures of people doing that thing. - Jmabel ! talk 07:14, 10 February 2019 (UTC)
We have Category:Women called queens (which oddly includes those called "princesses" as well); no analogous category for male winners of drag pageants given that title, nor a Category:Men called kings. If anything, AnonMoos's remark about "Lord Mayor" would be more of an objection to this existing category than to what I'm proposing. - Jmabel ! talk 07:21, 10 February 2019 (UTC)
Is this not what you are looking for? Category:Carnival Corte Oxyman (обговорення) 11:47, 10 February 2019 (UTC)
It's another example, but it is specific to Carnival (a celebration on or just before Shrove Tuesday a.k.a. Mardi Gras, Fat Tuesday, etc. What I'm saying is that we lack a broader category for this not tied to a particular time of year. - Jmabel ! talk 17:58, 10 February 2019 (UTC)
The description for Category:Carnivals says: Carnival, the carnival season, and other holidays called "carnival" or similar that include masquerade. It seems your interpretation of the Word Carnival is unusually specific here. Cambridge Dictionary defines Carnival as: (a special occasion or period of) public enjoyment and entertainment involving wearing unusual clothes, dancing, and eating and drinking, usually held in the streets of a city: https://dictionary.cambridge.org/dictionary/english/carnival it seems this category suffices Oxyman (обговорення) 18:13, 10 February 2019 (UTC)
Category:People with fictional royal titles or Category:People with fictional styles could cover the King of Pop, Queen Latifah, and maybe the Duke of Earl. Then there are the Prom Kings and Prom Queens.   — Jeff G. please ping or talk to me 18:11, 10 February 2019 (UTC)
I'm pretty sure that even though "carnival" doesn't always mean Shrove Tuesday, "Carnival corte" is pretty specific to the holiday. I'd be interested in seeing an English-language citation that uses the term in a context unrelated to Mardi Gras.
Category:People with fictional royal titles seems a good choice and that's where I'll go with this. - Jmabel ! talk 20:34, 10 February 2019 (UTC)
Hm. That term seems to cover a wide assortment of different instances. Might it be useful to subcategorize, eg "royalty" of fun fairs, "royalty" of Carnival (the calendric holiday), nicknames, etc. For Carnival royalty, would that apply to people more notable for other things to them as a person, or just for media while they are serving in that role (for example, should Category:Bob Hope have the category added, or just File:Bob_Hope_as_King_of_Bacchus_at_New_Orleans_Mardi_Gras_1973.jpg which shows in in the role of monarch of a Carnival Krewe? (See: en:w:Krewe_of_Bacchus#Celebrity_Monarchs) Also relevant: en:w:Jazz royalty. -- Infrogmation of New Orleans (обговорення) 06:49, 11 February 2019 (UTC)
Feel free to subcategorize as appropriate. I think if someone is well known as Carnival royalty over the years, and we have a category for that person, then their role as Carnival royalty belongs as a parent of their subcat; otherwise, it should just go on photos of them related to that role. Note that we had that issue even before adding Category:People with fictional royal titles. - Jmabel ! talk 16:47, 11 February 2019 (UTC)
Do not categorize Bob Hope as Category:People with fictional royal titles just because he appeared in a parade once or twice. Would we categorize every actor who played the titular role of King Lear? IMO, unchecked hyper-, meta-, and over-categorization leads to inefficient searching, clutter, and confusing, unhelpful cross-categorization . For just 1 example, searching for Good images of "Category:Kings brings up this image of a seagull, merely because it's in a subcategory of Cities named after monarchs. Is it realistic to expect that a user looking for images of Kings wants to find a bird? Is it realistic that anyone beyond us constant gardeners will be looking for Bob Hope (or anybody) based on the trivial fact that they (once) had "Queen", "Prince" or "Duke" in their name or title? --Animalparty (обговорення) 21:10, 11 February 2019 (UTC)
Having now observed that "carnival" doesn't always mean Shrove Tuesday, Corte means good breeding ie royalty. I find it odd to add more meaning then what is contained within the words used. I'd be interested in seeing an English-language citation that claims the term can only be used for Shrove Tuesday. Oxyman (обговорення) 23:11, 11 February 2019 (UTC)
The word “carnival” can indeed refer to several different things, but IME the unqualified, capitalized “Carnival” almost always means a Mardi Gras festival.—Odysseus1479 (talk) 23:33, 11 February 2019 (UTC)
Besides agreeing with what Odysseus1479 just said... @Oxyman:, what you are asking is as if you asked for a source explicitly saying that we only call something a "Halloween costume" when its worn on or around Halloween, or that we only call something a birthday present when it is given on or near the recipient's birthday, or that when we talk about an animal that "has feathers" we don't mean a cat that just ate a hummingbird and has feathers dangling from its mouth. If you think the term Carnival Corte is ever used to refer to things at other times of year, I really think the burden of proof is on you. Certainly all of the first 50 Google hits I found used it in the sense I understand the term. - Jmabel ! talk 00:25, 12 February 2019 (UTC)
Most categories start with a capital letter including Category:Carnivals which states that it doesn't just mean Shrove Tuesday carnivals, I do not think your similes are relevant as we have already observed the word carnival doesn't always mean Shrove Tuesday. I find your peculiar definitions extremely archaic and irrelevant. I am also not seeing the same 50 Google hits as you claim. As i stated before and restate as it is extremely relevant carnival doesn't always mean Shrove Tuesday, Corte means good breeding ie royalty. I really think the burden of proof should be on you. You are claiming the words mean something that is not in the meanings of the words themselves and backing that claim up with irrelevant similes. A bit like saying a Christmas decoration is not a Christmas decoration when it is in storage waiting for that time of year. Maybe you come from an extremely religious culture and that is coloring your thinking here. Oxyman (обговорення) 02:18, 12 February 2019 (UTC)
Wow, let's go all ad hominem here, shall we? For the record, I'm a secular person of Jewish background. And I've never seen the term Carnival corte used to refer to anything other than Mardi Gras. In particular, I have never heard anyone apply the term to, say, Seafair royalty or Pasadena's Rose Queen or anything of the sort, but it's almost impossible to demonstrate a negative that the term is never used that way. I believe it is incumbent upon you to come up with at least a couple of citations of such uses -- not just that it would in theory make etymological sense, but that the term is actually used that way. And until you have such citations, I'm done discussing it. - Jmabel ! talk 04:29, 12 February 2019
Wow let's get all offended here shall we, I said Maybe you come from an extremely religious culture and that is coloring your thinking here. Not that you are religious yourself. I can only know how words are used in the society I live and by using other sources like the dictionary one I linked to (I note you have provided no such links to your claims). I find your peculiar definitions extremely archaic and irrelevant. Having said yourself it makes etymological sense. What more can be expected from a category name? I believe it is incumbent upon you to demonstrate that we should add our own meanings to combinations of words as we see fit. Where is the policy on that? I also know that for instance buskers in Metro stations or subway underpasses are contained within Category:Street musicians. So think it well within reason to use this existing category. You do realise that you started this conversation asking for a response and then you pinged me for a response. I see no reason for you to fain offense that I answered your posts and attempted to point out that perhaps your vision is a little blinkered here. But if you're done discussing it then fine, I do not see why you post here at all. Oxyman (обговорення) 04:54, 12 February 2019 (UTC)

files with no sources[ред.]

I recently notice early uploads are tagged with no source and deleted afterwards, even though the uploaders provided enough information. They appear no source because someone else puts the {{information}} but does not write down anything. Examples:

  1. File:Cam degree ceremony.jpg
  2. File:Cotes-Inde du Sud.png Yann: Source is there, but I am not sure, it is OK. Wrong tag anyway. Roy: Source (S) is user-created. upct.org can be found in Internet Archive (IA). Free indeed. Licence (L) is GFDL.
  3. File:Carnaval2005.jpg R: S+L=PD-self. Could Markatú be a nickname/diminutive of Marcmacia? I don't speak Spanish so I don't know, but I assume good faith in this.
  4. File:Carmen Bozak.jpg Y: Source is there, but dead. Wrong tag. R: S is there but dead (found in IA, PD indeed).
  5. File:Corvo.png R: S=user-created. L=GFDL.
  6. File:Carlos terres.jpg R: S+L=PD-self.
  7. File:CarleRunge.jpg Y: Source is GLAM, no problem here.
  8. File:Carl Chinn Nov 2008.jpg Y: Source is there, but ARR. Wrong tag. R: S was not really there, but it could be seen in the original upload log. It was cut short by the file transfer bot. Until the time of tagging, no one had asked for the flickr source. I did that a few hours ago so an enwiki admin filled it up. (The image does not match the source though. Now it is no source indeed.)

It becomes even worse when admins delete such files without checking carefully. Non admins would not be able to check afterwards, because most deletion summary is a one liner no source since some date.

I do not think this is a new phenomenon. I have no idea what can be done to prevent such things happening again and again. To follow hasty deletion constantly is impossible.--Roy17 (обговорення) 17:32, 10 February 2019 (UTC)

https://commons.wikimedia.org/w/index.php?title=File:Cam_degree_ceremony.jpg&diff=113357229&oldid=57543098
This wouldn't be a problem if we didn't have bot-like edits like https://commons.wikimedia.org/w/index.php?title=File:Cam_degree_ceremony.jpg&diff=336173538&oldid=203227140 and bot-like deletions. But we do, and they clearly damage the project. - Alexis Jazz ping plz 17:45, 10 February 2019 (UTC)
I find File:Cam_degree_ceremony.jpg quite discutable. In 2005, {PD-self} was added by just leaving a standard checkmark in place. There is no explicit own work statement for this file at all. UDR was based on no more than assumptions. Jcb (обговорення) 18:20, 10 February 2019 (UTC)
We have already had this discussion. And you're not nominating every single {{own}} {{cc-by-sa-4.0}} image either. Make a proposal if you plan on any such thing. - Alexis Jazz ping plz 19:18, 10 February 2019 (UTC)
I added some comments inline. Regards, Yann (обговорення) 18:54, 10 February 2019 (UTC)
I added more comments inline. All these had actual sources. Whether or not they are questionable is another story. I also think it's understandable that users may overlook and put a wrong tag, but all these instances above were tagged by the same user.--Roy17 (обговорення) 00:16, 11 February 2019 (UTC)
Why does "no source" even exist? I just took a look at Category:Media without a source as of 7 February 2019. What do I find there? A load of stuff that may as well be tagged with "no permission". And a bunch of files like File:D'après Delaplace, Jean Nicolas Démeunier, gravure, musée Baron Martin.jpg. Damn crosswiki uploads, that's not own work. My French is not all that, but it says "1789" at the bottom of the document. I think the copyright holder has turned to dust by now, so why are such files in a speedy deletion category? Another example: File:Albert Baertsoen, Ferme flamande, le soir, huile sur toile, musée Baron Martin.jpg. Chances are if nobody looks at this, it would be deleted. But there actually is a source, in the description. Damn crosswiki uploads. It's PD. - Alexis Jazz ping plz 19:18, 10 February 2019 (UTC)
A few years ago I have proposed to dismantle the 'no source since' (and even the 'no permission since') process and to demand a regular DR instead. This has the big advantage that the nominator has to tell what's wrong. In case of the taggings, often the admin has to guess why it was tagged. Taggings are often poorly used. E.g. blatant copyright violations are tagged as 'no source' while the source link is present. Such a file gets deleted in the end, but not for the reason it was tagged for. At the time there was no consensus for my proposal, but I would still support such a thing. Jcb (обговорення) 19:36, 10 February 2019 (UTC)
Fixed licensing on both of those. Abzeronow (обговорення) 19:44, 10 February 2019 (UTC)
Notice the two examples given by Alexis Jazz were tagged by VFC. I wonder whether the person who tagged had actually looked at the files one by one or not.--Roy17 (обговорення) 21:27, 10 February 2019 (UTC)
@Roy17, Abzeronow: Also note that Ronhjones tagged all of Brioliv's files for deletion, and it's all similar stuff. - Alexis Jazz ping plz 00:43, 11 February 2019 (UTC)
when is it that you will trout those editors who persist in abusing the "no license" prod, rather than fixing licenses, or using consensus deletion process? look at all the waste of everyone else's time. Slowking4 § Sander.v.Ginkel's revenge 10:50, 12 February 2019 (UTC)
I have fixed 10 of User:Castillo blanco's no source nominations between 5 and 7 Feb. Older ones have been deleted. I wonder how many could have been saved too. And this is just one user. Could there be other mis-tagging too?--Roy17 (обговорення) 20:51, 13 February 2019 (UTC)

Who can remove nsd, npd, nld, nopd, etc.?[ред.]

Unlike speedy deletion templates, these tags of No XX Since do not have explicit instruction on how to properly get rid of them. Are only admins allowed to remove them? Or can any user remove them after problems are fixed?--Roy17 (обговорення) 22:34, 10 February 2019 (UTC)

There is no general agreement about that. I used to remove those speedy deletion tags. After a few "out of process removal" remarks from admins (no sanctions though), I stopped doing that. It only stopped me from being able to actually see admins perform bad actions as I was doing their work for them. Now I would watch such file pages. An admin should remove the speedy tag after some time, possibly open a DR. If they delete the file instead, I go to COM:REFUND. Anyone is allowed to remove those speedy tags if they open a DR at the same time. - Alexis Jazz ping plz 00:43, 11 February 2019 (UTC)

How do I search my Upload log just for images that were deleted?[ред.]

I am trying to find the original version of an image I took in a cemetery 2006 and added at sometime here. My notes said that the original was deleted and I had to upload a cropped version which lost the metadata. I want to find the filename of the original so that I can get it restored and read the metadata. RAN (обговорення) 21:04, 10 February 2019 (UTC)

[11]. The deleted files will have red links. --Majora (обговорення) 21:12, 10 February 2019 (UTC)
see also [12] Slowking4 § Sander.v.Ginkel's revenge 18:06, 13 February 2019 (UTC)

How to deal with substantially altered images?[ред.]

File:Natascha McElhone.jpg was given through OTRS. I believe it is not appropriate to overwrite it with a cropped and retouched one, but I cannot upload the retouched pic separately because of duplicating. What is the standard procedure for this kind of files?--Roy17 (обговорення) 21:16, 10 February 2019 (UTC)

They can be split by an administrator. You can add {{Split}} to request it. --ghouston (обговорення) 22:31, 10 February 2019 (UTC)
@Ghouston: Thanks a lot! It's kinda weird though. I had this problem before and I did revert-this-and-upload-that. No idea how the software works...--Roy17 (обговорення) 22:44, 10 February 2019 (UTC)
I'm not sure, it seems like it checks for for checksum matches, sometimes, but not always. Maybe it depends on the upload method. --ghouston (обговорення) 22:46, 10 February 2019 (UTC)

February 11[ред.]

Stop the vandalistic blanking of user pages[ред.]

For years now I’ve observed the practice of users blanking the user pages of indefinitely blocked users, this seems to happen cross-wiki and seems to happen, how the practice basically works is that if a user gets blocked with no expiration data their user pages will typically get blanked by another user, this user can be the blocking admin or a casual observer, more often than not it's done by someone who has a dispute with the user and their user page will then be replaced with a template indicating that this user is indefinitely blocked. In many cases these people have been contributors for a long time and have had their fair share of contributions to the project, one would think that as a bit of decent courtesy we (as a community) would allow these people who involuntarily have to depart from the project could at least have a little space dedicated to them and how they feel about the project(s) that they have contributed to, but that really is too much to ask if you'd ask most Wikimedians for some reason. Now conversely if one would look at the common tactic of vandals used where the blank their target’s user pages this is seen as “disruptive vandalism” and gets rightfully reverted, but somehow what is considered vandalism when the target is some users becomes wholly acceptable when other users are being targeted.

I remember in 2017 I was looking at the image “File:Qing Dynasty 500 Cash.jpg” and by coincidence clicked on the uploader’s name to land on this page (Mobile 📱), now looking at its history we see this:

The previous version looked like this (Mobile 📱), an inoffensive user page containing a couple of high quality paintings and a quote, this user was a dedicated photographer who went out of his way to visit museums all over Poland and take high quality pictures that grace many pages across Wikimedia websites and beyond. Yet today any photograph he took is only two (2) clicks away from an empty page with essentially “a go away message” and no evidence that this user was ever anything more here than forever banned from contributing.

While discussing “WikiCulture” with a friend of mine who is a Dutch biology professor at a university where I used to work and expressed interest in contributing to Wikispecies because some of his students were using it, I explained how user pages would routinely get blanked and people’s photographs of themselves deleted (Link 🔗 / Mobile 📱) simply based on their current blocks and he described it as “petty” later citing that he would not look forward working with people who think that such behaviour is acceptable, in fact to any outsider any edit done by an account, any image uploaded, any minor contribution and/or comment links to their user page and their talk page. A person browsing Wikimedia Commons is very likely to run across an image uploaded by Russavia or an image deleted by INeverCry and then only find blank pages with notices of their ban, nothing left of what contributions they’ve made or which contributions they’re most proud of, just a blank page with a “persona non grata” message, while sure some other websites such as message boards delete any profile pages of banned users and the Facebook erases any reference to your existence including any comments you’ve ever made and/or posts you’ve ever made, but their intent different from what a Wikimedia website should be about. Wikimedia contributors are also the copyright © holders of their edits, any edit is their copyright and its not uncommon for the blanking of user pages to also entail removing any contact details relating to these users, not everyone knows how the “history” tab works.

I haven't been able to find any local policies that advocate the blanking of user pages, but it seems to be a de facto standard across almost all Wikimedia websites, in fact it's quite odd how often this unwritten rule gets applied, it seems to be the only consistent thing among almost a thousand different projects. A few exceptions exist but in cases of a WMF Global Ban the Wikimedia Foundation office account always blanks all content, including talk pages (Mobile 📱), and also on Wikimedia websites where blanking blocker users’ user pages isn't even a thing (Mobile 📱) which means that the Wikimedia Foundation (WMF) simply doesn't respect local policies and adopts the most punitive ones on a whim. Of course the exception is when there are already tags indicating that this user has been blocked and/or banned before, this seems like a move that would superficially legitimise the Wikimedia Foundation’s actions by saying “look, see the community didn't want this human being here either, so we're not circumventing any community consensus here”, but the Wikimedia Foundation ignoring the independence of local communities is a whole other issue I’d rather not get too deep in here.

The former Wikimedia Commons admin INeverCry and several others even went so far as to first deleting user pages before tagging them with a block notice, this seems overly punitive, let’s say that Wikimedians would actually have to stay true to the original principles of the community and not the heavily Exclusionist principles later adopted which have become the de facto (and unwritten) standards every rule has to be interpreted with today, and blocks were actually seen as a preventive and temporary measure. Let’s take the example of page “User:DLindsley” which if you would look at its history (Mobile 📱, as of January 17th (seventeenth), 2019) only contains a single edit by the user known as “INeverCry”, the argument usually goes that after a user gets unblocked that they could restore their own user page and/or that if anyone is interested in seeing a prior version of the user page that one can visit the “History” of that page, but the user “INeverCry” (later with their ADMINSOCK “Daphne Lantier”) constantly deleted user pages of indefinitely blocked users, what message does this send to both the community and the human being behind the blocked account? In fact, people went out of their way to restore INeverCry’s user page after he deleted it, himself (Mobile 📱, I couldn't find the original discussion). But if you look at logs of the page “User:DLindsley” you could see that this was deleted (Mobile 📱) at “02:34, 3 March 2015 INeverCry (talk | contribs) deleted page User:DLindsley (Userpage of indefinitely blocked user) (thank)”, but nowhere does the rejected user page policy state that they have to be deleted if a user has been indefinitely blocked. So why do we allow sysops to create their own rules and unwritten guidelines relating to actions only they are permitted to take? In fact this makes the legitimacy of INeverCry’s half a million log actions (Mobile 📱) even more questionable. On Wikimedia Commons every file links to its uploader, and if a banned uploader has so many uploads that if you click on “random” that you keep running into them then an empty page with only a tag could be very discouraging to newcomers (“noobs”) and outsiders.

This brings me to the question who benefits from blanking user pages? Seriously, which party actually has a benefit from seeing a user page blanked? Because the casual readers surely don't benefit from it. When I look at the systematic blanking of indefinitely blocked users’ pages I see the same behaviour vandals or otherwise good contributors who are disgruntled at a certain person do, they blank the pages of users they don't like but in this context it is rightly seen as vandalism, but in this specific case it's somehow acceptable. It is gravedancing, no matter how you spin it, in fact if you Ecosia search “legitimate gravedancing” among the first results is the Wikipediocracy article “‘Tis the Season to be Banning at Wikipedia” by Mason, this article notes that the practice of blanking is not only a form of gravedancing but one that’s mostly performed by people who dislike the banned person.

But one of the main reasons why I dislike this practise sends a bad message to the blocked person, while officially the Wikimedia Commons blocking policy states “blocking is designed to be a preventative measure and not a punitive one”, but blanking a user page completely negates this intention, also if a user is expected to be able to return if they can successfully appeal their block, then why blank their user page? This sends the message that it's permanent (which is probably is seeing how few users successfully return from indefinite blocks), it is simply not a collegial thing to do and does not benefit either “the community” or the project, so I suggest ceasing the blanking of blocked user pages altogether.

TL;DR version:

When user pages are basically CV or promotional or contain personal attacks or otherwise content that’s not allowed we remove the content or delete the user pages, this is normal as user pages are not meant for these things and such content is harmful for the community, meanwhile acceptable user pages which may contain instructions on how re-users should attribute them or could directly link to featured images or other high quality images uploaded by them (Mobile 📱) which potential re-users might be interested in, but for whatever reason it's acceptable to treat these pages as if they’re pure vandalism and blank them (Mobile 📱). For this reason I would like to propose to treat the blanking of indefinitely blocked users’ user pages like the blanking of “regular user pages” that if they do not contain anything offensive or advertising something external (excluding GLAM’s) should not simply by blanked because it comes off as petty and uncollegial. Furthermore the current practice of blanking (or even deleting) user pages of indefinitely blocked users is not a community policy and just seems to be an unwritten rule the community never voted on and can not be seen as anything other than bad faith editing or even gravedancing as it appears as a punitive measure.

in short

I propose for the user pages of indefinitely blocked users to look like (and be tagged like) this (Mobile 📱) and this (Mobile 📱) rather than this (Mobile 📱). --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 20:30, 11 February 2019 (UTC)

  • I agree that blanking pages that would otherwise be acceptable is pointlessly aggressive. Obviously, we have to be free to blank indef-banned users' pages if the page content would be unacceptable from an active user, and maybe there should be a little more leeway to remove self-promotional content from the user page of an indef-banned user than one in good standing, but that's about it. - Jmabel ! talk 00:36, 12 February 2019 (UTC)
  • Was it really necessary to write a 15,000 byte rant with multiple, line interrupting, unnecessary, emojis to say that? It is standard practice to replace the user pages of blocked socks with the sock notice both here and on the English Wikipedia where you are taking your policy advice from. As for regularly indefinite blocked individuals, I agree that deleting the user pages is a bit much but replacing them is also pretty standard practice here and on enwiki depending on the circumstance. The page's history maintains a record of what was once there provided the page isn't actually deleted. Using INC to justify your rant is just poor form. We are not all INC. --Majora (обговорення) 01:49, 12 February 2019 (UTC)
  • Symbol support vote.svg За Blanking a blocked or banned user's page should only be done where there is a clear rationale for doing so. This may include harassing other users or other ranty stuff, but if the page is neutral and informative, there are no good reasons for blanking and it should not happen because "bureaucracy". P.s. yes this proposal is far too long, please consider collapsing most of the text/essay. P.p.s I believe this issue was discussed, perhaps 3 years ago, though I am unsure there was ever a vote about it. -- (обговорення) 10:58, 12 February 2019 (UTC)
  • I agree with Donald's point that most user pages should not be replaced by a single block notice. The first few times I had seen this on other wikis, I found it unreasonable. Most user pages do not contain stuff harmful to the project. Why not simply put the block notice on top and leave everything else in its shape? It's also often troublesome to find out who the blocked user is and why s/he was blocked. Most block logs contain some one-liners that do not link to the actual grievances.--Roy17 (обговорення) 11:56, 12 February 2019 (UTC)
  • Symbol support vote.svg За yes, better as an essay first, and then developed as a consensus standard of practice proposal, like d:Wikidata:Behavior norms Slowking4 § Sander.v.Ginkel's revenge 13:48, 12 February 2019 (UTC)
  • Symbol support vote.svg За. It should never have been allowed to become a habit, and that habit needs to stop. -- Tuválkin 16:03, 12 February 2019 (UTC)
  • Pictogram voting comment.svg Коментар Although I mostly agree with which was exposed about unnecessary "gravedancing" and being over-"vindictive", having ad æternum a picture of themselves, their name or other personal data next to templates such as {{autotranslate|1=|base=indefblockeduser}} {{WMF-legal banned user}} or {{sockpuppeteer}} may be detrimental to the blocked user, and (in fact) administrator removing that stuff may be doing the blocked user a favor. Strakhov (обговорення) 16:22, 12 February 2019 (UTC)
  • I'd probably support this, but this is really TLDR. Also, if a blocked user requests their user page to be blanked or have some elements (like a photo) removed from it, such a request should be honored. - Alexis Jazz ping plz 16:58, 12 February 2019 (UTC)

February 12[ред.]

What is all this computer code for? are all the brackets and slashes and abbreviations on every page here supposed to do? Where is there an interpretation for them.[ред.]

What are all the brackets and slashes and abbreviations on every page here supposed to do? Where is there an interpretation for them? How am I supposed to figure this out.

There are NO explanations anywhere for the layman to understand how all this coding gibberish works, what it means or even if it is important.

Nobody has explained that, tho I have asked several places on here. Who can TELL me this stuff and DO NOT refer me to any other pages, because none of them address this.

I am trying to understand and am not getting any help.

Thanks.
— Цей непідписаний коментар додано Gsdcraig (обговорення • внесок) 02:25, 12 February 2019 (UTC)
Multiple people have already tried to help you. Your user talk page, found here: User talk:Gsdcraig, contain many messages to that affect. Wikipedia also has a tutorial where you can learn how to edit here: w:Wikipedia:Tutorial. You can also avoid all the coding that you are talking about by clicking on the "Beta" link in the upper right hand corner and enabling the "Visual editing" beta feature. This will turn on a "what you see is what you get" type editor that allows you to edit pages directly. --Majora (обговорення) 03:07, 12 February 2019 (UTC)
consider this a periodic reminder of just how opaque the UX is to newbies. wiki'splaining will not help; not everyone can edit; there is a threshold of understanding of computer interfaces required. Slowking4 § Sander.v.Ginkel's revenge 17:38, 13 February 2019 (UTC)
  • Maybe we should try and make a wiki wthout the use of any computers? Though I suspect that there will always be someone moaning about what’s this paper and pencil geekery, pushing for fingerpainting-only. -- Tuválkin 19:11, 15 February 2019 (UTC)

Automated method to create Template and Categories[ред.]

Hi, I am seeking for advice how to create Wikmedia Commons Template and Categorie Pages automated way. Would you please suggest the tools I need to look for. Thank you. Grybukas (обговорення) 15:00, 12 February 2019 (UTC)

Way to exclude PDF from search?[ред.]

Is there a way to exclude books from searches for images? They are starting to clog the whole thing, on some search parameters there are thousands of hits for books with much much less images to be found. The images mostly come before the books, but not all... Anybody got a solution? ~ R.T.G 18:04, 12 February 2019 (UTC)

@RTG: -intitle:pdf - Alexis Jazz ping plz 18:17, 12 February 2019 (UTC)
Thank you o7 ~ R.T.G 18:55, 12 February 2019 (UTC)

Wikidata RfC related to the inclusion of Wikimedia Commons categories[ред.]

Everyone is invited to give their opinion whether or not Wikidata should allow for the inclusion of items with only a Wikimedia Commons category, this request for comment was started to help the Structured Data on Wikimedia Commons programme and could be found on Wikidata at "Wikidata:Wikidata:Requests for comment/Allow for Wikidata items to be created that only link to a single Wikimedia Commons category (Wikidata notability discussion)". Note that this request for comment is on Wikidata so following that link will take you off Wikimedia Commons (as if this website is a wikidrug Face-smile.svg). --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 19:22, 12 February 2019 (UTC)

This should be a Commons RFC, surely? By far the largest affected community is here. -- (обговорення) 19:55, 12 February 2019 (UTC)
No, because the actual change would be WD side, based on their notability criteria. Local community has to change local policy. GMGtalk 20:03, 12 February 2019 (UTC)
Cool, well I'll leave them to it. Nothing to do with me. -- (обговорення) 20:15, 12 February 2019 (UTC)

Captions[ред.]

These (see 10 Dec, 'Captions are live', at the top of this page) have reappeared on every file, even though I've got them set to Hidden in my preferences. How can I get rid of them again, please? MPF (обговорення) 23:15, 12 February 2019 (UTC)

@MPF: They are back for me, too. I had been using Collapse, which is not working at present. Compact and Hide are also not working.   — Jeff G. please ping or talk to me 23:25, 12 February 2019 (UTC)
The development team is currently deploying some new code to notify users about the CC0 license (there's some bug fixing ongoing to fix a problem with system messages that didn't show up on TestCommons). There may need to be some tweaking to the gadget (@Jean-Frédéric:), I'll know more very shortly. Keegan (WMF) (обговорення) 23:30, 12 February 2019 (UTC)
@MPF, Jeff G.: fixed now, wbmi-entityview-content was renamed to wbmi-entityview-captionsPanel. Sorry about that. Keegan (WMF) (обговорення) 23:39, 12 February 2019 (UTC)
@Jdforrester (WMF): Thanks for fixing it. @Keegan (WMF): Thanks for letting us know.   — Jeff G. please ping or talk to me 23:54, 12 February 2019 (UTC)
@Keegan (WMF): excellent, thanks! - MPF (обговорення) 23:57, 12 February 2019 (UTC)

February 13[ред.]

North Macedonia[ред.]

As some of you may have noticed, the Republic of Macedonia has officially changed its name to North Macedonia in order to make the Greeks feel content. The user @Michaeldsuarez: is doing wrong, see the mess he's doing (here, for example). We must coordinate and make a moving plan and most of all doing it well. -- SERGIO (aka the Blackcat) 16:21, 13 February 2019 (UTC)

En.wiki's page uses North Macedonia now as the country's name. Perhaps a large categories for discussion entry is in order, but I don't see anything wrong with updating categories so they reflect the new name of the country. Abzeronow (обговорення) 18:15, 13 February 2019 (UTC)
I'm not sure I understand what the problem is. They've been talking about this for quite a while. I'm not sure there's very much chance that it's going to be reversed. GMGtalk 18:21, 13 February 2019 (UTC)
According to the link offered by Blackcat, this Michaeldsuarez account would be moving the categories but not the files inside of them. I agree a bot-like approach would be welcomed, less time-consuming. Strakhov (обговорення) 18:34, 13 February 2019 (UTC)
Of course @GreenMeansGo:, nobody talks about rolling the changes back. But the current situation is - at the best - very messy because it's being handled poorly and without a schema. As @Strakhov: said, such major changes must be bot-made, not hand's -- SERGIO (aka the Blackcat) 00:27, 14 February 2019 (UTC)
If someone does manually what a bot might do otherwise, have we really lost anything but redundant effort? Is it causing any active damage? I presume much of what I currently do on this project can be taken over by a bot in the next 20 or so years when facial recognition becomes better tuned. GMGtalk 00:33, 14 February 2019 (UTC)

Lasvegasvegas.com[ред.]

Lasvegasvegas.com has been dead for a while.. I recently requested license reviews for Category:Images from lasvegasvegas.com that should have been requested at upload time. It appears the LR queue has now gotten to these.

For some, archive.org works. Fæ added links for those. For others, like File:2011 November Nine.jpg we can confirm this is a photo by flipchip because the photo was re-used and credited elsewhere: http://www.poker-base.com/news/the_best_poker_players_come_around_at_live_events.aspx.

Pinging @4nn1l2, GRuban, Leoboudv, Roy17, Chiyako92. - Alexis Jazz ping plz 16:39, 13 February 2019 (UTC)

Now that I think about it, we may also need to check in those cases of re-use that they didn't get it from Commons. Sadly, poker-base got it here. We may need to find some other way. - Alexis Jazz ping plz 16:54, 13 February 2019 (UTC)
Will look, eventually; but honestly, most of these images that we don't find in the Internet Archive should be fairly safe. They're not professionally posed, they're just "person at an expo taken by another person at the same expo", which we generally accept without difficulty, and the lasvegasvegas.com permissions statement is archived. Also, I reiterate the call for Alexis to reapply for License Reviewer status. --GRuban (обговорення) 17:38, 13 February 2019 (UTC)
@GRuban: I mocked something up in my incubator that would take care of most of these if accepted. I noticed many images were uploaded by an OTRS member and also some do have a license review. Me becoming a license reviewer.. Strakhov's poke at not reviewing my own essays suggests a "no", sadly. Ruthven's suggestion for me to apply for adminship is even more certain to go unanswered. (for more than one reason) If any position impairs my freedom of speech, I'm not interested. - Alexis Jazz ping plz 17:58, 13 February 2019 (UTC)
Strakhov was joking, they said so right there. You can be a license reviewer and keep your acidic essays; if you're talking about the contents of your user page, then I can't see anything there that says either "I will approve copyright violations" or "I will not approve free images I don't like". Admin, maybe not, but that's because that involves interacting with and even blocking people, and, yes, some of your user page comments may well offend people. I'd encourage you to soften them (admins, even deleting ones, are trying to make things better here too, honest), but it shouldn't be a requirement. I think we can trust you with not hurting the feelings of image files. See, you are knowledgeable and have a huge amount of energy. That's a valuable combination. We're a volunteer project, we don't have limitless resources, we can't let that get away. --GRuban (обговорення) 18:10, 13 February 2019 (UTC)
@Alexis Jazz: I was certainly joking (i would not do that anymore!). I liked some of those essays and, most important, I just can't see the relationship between writing essays-some-commons-users-do-not like and the ability of stating "OK" to a license in the internet. Strakhov (обговорення) 01:43, 14 February 2019 (UTC)
@Strakhov: I am glad to hear that! It's hard to keep track of who said what. There are some users who were overjoyed with the deletion of my essays, while some others were deeply uncomfortable with it and probably questioning what it means for freedom of speech on Commons. And just because I haven't filed a UDR yet doesn't mean I accept their deletion. I haven't accepted The Huntington deletion fiasco or the TechCrunch deletions either. If I am to apply for LR, I don't want that to be controversial. It all comes down to trust. @Sixflashphoto: you were one of the opposers on my original LR request. Would you still oppose me? - Alexis Jazz ping plz 02:26, 14 February 2019 (UTC)
Based just on what I remember form June to a few months ago; I still have some concerns on a penchant for conflict but that shouldn't stop you from LR. I sometimes thought you tried to work around policies rather than by policy but I have less of a concern about that then I had previously. I want to say I’ve been taking care of some very serious family medical issues now and these past few months so I haven’t been able to be around and my thoughts should be taken into account accordingly. -- Sixflashphoto (обговорення) 17:59, 14 February 2019 (UTC)

Caption license changed to CC-0[ред.]

2019-02-13 Captions and other structured data contributions — WMF CC0 — pop-up.jpg

Hi folks. I REALLY welcomed the new caption feature. While I took every precaution to give my uploads meaningful names (for English-speaking readers), other contributors didn't. And changing inappropriate filenames is no fun at all. The caption feature seemed to be helpful, and it allowed for different language versions.

But I will NEVER make a substantial contribution to Wikimedia or Wikipedia under the CC-0 license. If Amazon, Google, Facebook or any other commercial venture wants to make profit out of my work, they have to recognize my authorship (BY) and redistribute their derived work under the same license (SA). Alternatively, they are allowed to send me a job offer BEFORE taking my work for granted.

Sometimes in the last 24 hours the upload wizard has been updated, it requires the uploader to accept CC-0 for the caption line. As a consequence, I will stop contributing caption lines. And I think over, whether contributing to a Wikidata-dominated pile of poop (Wikimedia Commons), or another Wikidata-dominated pile of poop (Wikipedia), steered and paid by multinational tax defrauding a**hole groups like Google, is acceptable at all. Love, --Natalie Freyaldenhoven (обговорення) 21:02, 13 February 2019 (UTC)

Yep. If you see your previous captions being given CC0 status, you may wish to send WMF Legal a take down notice. -- (обговорення) 21:05, 13 February 2019 (UTC)
Hear! Boycot, please. Jürgen Eissink (обговорення) 21:42, 13 February 2019 (UTC).
This is really rather distasteful. When now editing a caption, you get the pop-up shown here. There doesn't seem to be an uncheck option for future edits, so with one click you irrevocabily accept the new regime. Jürgen Eissink (обговорення) 22:28, 13 February 2019 (UTC).
The design for the popup mimics the behavior of the CC0 notice on Wikidata. The acknowledgement is currently set by cookie here on Commons, but the development team plans on implementing a hidden preference as well. A user would be able to reset the warning by pressing the "Reset all my preferences" in Special:Preferences after this code is implemented. The development team is always interested in new ideas on how to show this notice without overloading the user for every caption edit made, so let them know if other options come to mind and we'll see if it's been considered already. Keegan (WMF) (обговорення) 22:50, 13 February 2019 (UTC)
You can point to the development team all you like, Keegan (WMF), but WMF should have announced, in all clarity, to all users a major change like this. But I think clarity is not part of the plan. Behavior like this might very well lead to a backfire you could not even have imagined. I, for one, am sort of disappointed, but I suddenly see quite clear what this is all about. And it ain't a pretty sight. Jürgen Eissink (обговорення) 01:57, 14 February 2019 (UTC).
just as behavior like this, from the community, might well get their non-constructive feedback deprecated in the future. Slowking4 § Sander.v.Ginkel's revenge 02:07, 14 February 2019 (UTC)
Do you want a ban on expressing feelings and insights, Slowking4? Is that the affection and behavior you would like to see established? A prohibition on criticism? Not in my world and life, Slowking4. Jürgen Eissink (обговорення) 02:19, 14 February 2019 (UTC).
don't know why you want to rant to the point of farce. wikidata has good reasons to use CC0, if you you do not want to work with that license, boycott, see what little impact it has on structured data. Slowking4 § Sander.v.Ginkel's revenge 02:28, 14 February 2019 (UTC)
I would be glad to have played you a little farce, but time will tell you if that is what I did. My indignation is sincere, whether you like trying to belittle it or not. Jürgen Eissink (обговорення) 02:41, 14 February 2019 (UTC).
i am sad you are indignant about this license trivia. a better target for your indignation would be [13]. you still have time to call your MP. Slowking4 § Sander.v.Ginkel's revenge 13:33, 14 February 2019 (UTC)
Do you really think the two are separate matters? And besides, you clearly don't know my background. Jürgen Eissink (обговорення) 15:16, 14 February 2019 (UTC).
While there is very little guidance on how captions should be worded, I suppose that a good caption would be simple enough to fall below the threshold of originality. A caption like "A picture of a chair" or "Painting by Pablo Picasso of a man reading" is probably not copyrightable anywhere. Anything more elaborate should probably be relegated to description field, which like all other text on Commons is CC-BY-SA by default. --Animalparty (обговорення) 22:48, 13 February 2019 (UTC)
I see now that this is already mentioned on COM:File captions: Only text which is so short that it is not copyrightable should be copied into captions, as it is likely that captions will be made available under a CC0 ("public domain") licence. (And yes, I'm replying to myself.) --Animalparty (обговорення) 02:47, 14 February 2019 (UTC)
Wait? Were is the community consensus? Natuur12 (обговорення) 22:49, 13 February 2019 (UTC)
Structured data on Commons must be CC0 out of necessity for the ecosystem of the project to interact with Wikidata, it's simply not optional. CC0 licensing only applies to captions and structured data spaces; the rest of licensing on Commons does not change. Keegan (WMF) (обговорення) 22:59, 13 February 2019 (UTC)
While I agree with you on the technicalities of having the caption fields being licensed as CC0 if we want it to interact with Wikidata (as it is currently structured), but I still am lacking the community consensus of requiring it to be licensed under such a license. Implementing something on a WMF-level and later claiming something to be "not optional" is totally overruling the community and playing the "superuser" card (even if I agree and am in favor of the feature). Simply having a formality-vote on the matter would have been much more beneficial for the relation between Commons <> WMF. --Jonatan Svensson Glad (talk) 23:07, 13 February 2019 (UTC)
@Keegan (WMF): Structured data on Commons must be CC0 out of necessity for the ecosystem of the project to interact with Wikidata This simply isn't true. Wikidata is licensed CC0, so SDC can take anything it needs from Wikidata. But that doesn't mean SDC has to be licensed CC0 -- we could equally well choose it to be licensed CC-SA or ODBL or whatever we wanted. If SDC was licensed ODBL, then one couldn't take content from SDC and transfer it to Wikidata. Which might be regrettable, but is hardly a "necessity for the ecosystem". In the other direction, data from wikidata would be freely combinable with data from SDC, so long as the combination was licensed ODBC (or whatever we went for for SDC). There genuinely was a choice to make here, and it is not clear that it was for the dev team to take, without consultation. Jheald (обговорення) 23:34, 13 February 2019 (UTC)
Which I think is misunderstanding what the captions are. They are Wikidata in Commons, not any generic form of structured data. It was created by and for Wikidata people.--Prosfilaes (обговорення) 23:48, 13 February 2019 (UTC)

The thing is that file captions (like all other Structured Data on Wikimedia Commons) was supposed to be Creative Commons 0 (Zero) out-of-the-box, but due to some miscommunications between WMF Legal and the people working on the upcoming Structured Data on Wikimedia Commons features the file captions "feature" was launched without the Creative Commons 0 (Zero) license. I immediately addressed the copyright © status of these file captions but unfortunately it took very long for this to be implemented leading to a lot of confusion. Hopefully the Wikimedia Foundation will have learned from this and won't forget to update the wording for the launch of future Structured Data on Wikimedia Commons services. 🤞🏻 --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 23:04, 13 February 2019 (UTC)

Correction: Short texts have no copyright is fakenews, spin, a fiction, a deliberately misleading untruth. WMF legal will never give volunteers immunity from later claims of damage. Go read some short poems or read up on database rights. -- (обговорення) 07:16, 14 February 2019 (UTC)

https://www.copyright.gov/help/faq/faq-protect.html#title says "Copyright does not protect names, titles, slogans, or short phrases.". I don't know what database rights have to do with this; just because you have a right over a database doesn't mean you have rights over every string in there.--Prosfilaes (обговорення) 20:16, 14 February 2019 (UTC)
If captions are cut and paste, they will be short text extracts, not short phrases. Any copyrighted work can be cut up into short texts, that does not mean those extracts must be copyright free. Similarly many databases of images I upload require attribution, including the metadata. Systematically extracting that data and calling each piece CC0, is a failure to respect the moral rights, which can end up as a claim of damages. -- (обговорення) 20:49, 14 February 2019 (UTC)
I don't buy your distinction between short text extracts and short phrases. Any copyrighted text on the Internet is made up of a series of numbers, 0-255 (or even 0 and 1), and these numbers are copyright free. At a certain point, when you assemble enough of these uncopyrightable elements into a longer work, it may be copyrightable. (Note that your interpretation calls into question any collection of possible copyrighted quotations, like Wikiquote.)
The US Copyright Office specifically refused to register "Sorry boys, Daddy says I can't date until I'm 30". Factual matters have weakened copyright; how many ways can you reasonably say "A stuffed Solenodon paradoxus at the Harvard Museum of Natural History, from San Domingo."?
Database rights are not an aspect of US law. Adding an entire database of works that have a claim of database on them does seem problematic. Why is CC0 any worse than a CC-BY-SA that doesn't bother clearly providing attribution?--Prosfilaes (обговорення) 22:12, 14 February 2019 (UTC)

So, I just checked the caption field again. There is still the requirement to publish captions under CC-0. No way, I won't contribute to Wikimedia Commons any longer. No captions, and nothing else. Bye, --Natalie Freyaldenhoven (обговорення) 11:00, 14 February 2019 (UTC)

Is the Wikimedia Commons community ready for another vote to remove "CC0 Captions", perhaps one not dominated by hardcore Wikidata fans? Similar to the Brexit vote, it is only after some time that everyone is a bit clearer on why speedily rolling this out, without having credible testing or an understanding of the consequences, might be damaging for Wikimedia Commons. In terms of copyright, this change is screwing around with the ethical respect for preserving attribution, fundamental to this project. -- (обговорення) 11:37, 14 February 2019 (UTC)

sure, bring on your vote. do you have a consensus? will it cement the reputation of commons as "not playing nice" with other projects? Slowking4 § Sander.v.Ginkel's revenge 13:41, 14 February 2019 (UTC)
Have you ever thought that maybe trying to stop Structured Commons is the equivalent of the Brexit vote. Much like Leave, some have an irrational hatred for Wikidata(the EU in this analogy). But sure, force the WMF to disregard the community here, what could possibly go wrong? Abzeronow (обговорення) 15:03, 14 February 2019 (UTC)
I see your point.   — Jeff G. please ping or talk to me 15:11, 14 February 2019 (UTC)
LOL! "Force the WMF to disregard the community" is the EXACT OPPOSITE of what having a consensus vote means. This really is bizarro Brexit style thinking. What next, having a vote is anti-democracy, having a vote is anti-consensus? Nuts. -- (обговорення) 15:14, 14 February 2019 (UTC)
Some people here are like presbyters mongering fear for WMF, it's ridiculous and grotesque, not to say it's the voice of evil itself. Be aware of those that have something to gain in denying reason. Fascism and tiranny are not something of the past, and it's always little men that are eager to pave the ways. Jürgen Eissink (обговорення) 15:38, 14 February 2019 (UTC).
I'm not sure evoking fascism and tyranny is really going to be terribly helpful in this discussion. If there's anything we need less of it's hyperbole. GMGtalk 15:43, 14 February 2019 (UTC)
Correct me if I'm wrong, I think this is the first time I have been called a "fascist" or someone who wants "tiranny" because I asked if a vote might be a good idea. Very strange, do folks really think that the WMF is infallible, and unlike other companies, must never be criticised or held to account? At this point it does feel like complaining about this change, is as controversial as saying that not everything in the Bible is literally true.
Would anyone object to me creating the alternate account of Voice_Of_Evil, so that I can play up to being a figure for irrational hatred when I create proposals, or would that tip the drama scale over into utter farce? -- (обговорення) 16:37, 14 February 2019 (UTC)
@: Dear , I wasn't referring to you, in fact quite the opposite. It must be my non-native English that is making my comment apparently wrong directed. I support your view, but not the views of some that I think you were opposing too. Sorry for the inconvenience - my fury must have been causing this misunderstanding. I will retract from this discussion, for now, since I am obviously doing it no good. I am not happy with the way WMF has introduced Structured Data, I think the whole project is a failure and in the current form should be canceled. Jürgen Eissink (обговорення) 16:57, 14 February 2019 (UTC).
Thanks, much clearer. Let's also be clear, the WMF is not evil, not even as evil as Google, and nobody working for them is a fascist or is known to worship Satan, all those I've met over the years have been jolly nice. Keep it non personal folks. -- (обговорення) 17:17, 14 February 2019 (UTC)
Jolly nice people can be ignorant of carrying intrinsicly bad ideas. There is no need to point to other tech giants or external laws when the problem lies inside. Jürgen Eissink (обговорення) 17:28, 14 February 2019 (UTC).
Other = Google was introduced in the 1st paragraph by Natalie Freyaldenhoven. I like WikiData, I like CC0 even more, and I trust Google as far as I can throw them, but those captions without a plan how to sync them with descriptions are silly. OTOH folks insisting on some "copyright" for captions are beyond hopeless. –84.46.53.251 15:13, 17 February 2019 (UTC)
The ethical respect for attribution is essential to this project? If you look at the Terms of Use, it says "When you contribute text, you agree to be attributed in any of the following fashions: Through hyperlink (where possible) or URL to the article to which you contributed (since each article has a history page that lists all authors and editors) ..." So a publisher can reprint an article for Wikipedia, that you wrote in full, with or without minor editing from others, and only have an obligation to print a note about CC-BY-SA from en.wikipedia.org/wiki/Your_Subject. In practice, the attribution on these captions is likely to be as good as an Wikipedia article; you'll almost invariably have a link to the Commons page wherein the editors can be looked up. Attribution on Wikimedia, except for photos, is a farce, and rationally, meaningfully assigning attribution is incredibly hard on something like a Wikipedia article, where the "real" authors are controversial and hard to figure out, and the authors who arguably have copyright interest can number in the hundreds.
I'm stunned by the number of people who seem to think that Wikimedia CC licenses are anti-business. Wikimedia doesn't use NC licenses for a reason. The CC-BY-SA is more than enough for big business to do amazing things within the license; it may be more of a restriction for open source authors who have to publicly distribute work, instead of avoiding copyright licenses by not copying work.--Prosfilaes (обговорення) 20:41, 14 February 2019 (UTC)
Sharing information and knowledge is key to the project. You don't get the point that through Wikidata and Stuctured Data WMF itself will be more and more able to exploit the submissions of its volunteers, the volunteers that are the reason for it's existence already. If monetizing the 'Data' is indeed the goal (and if not: why not use CC-BY-(SA)?), the whole project is entering a complete different universe. Jürgen Eissink (обговорення) 20:54, 14 February 2019 (UTC).
Exploit is an emotionally loaded word; it's one I'm sure the BSD developers would reject as they've rejected licenses like the GPL and CC-BY-SA. I don't understand what you mean by it. Do you consider Google's use of the Linux kernel in Android as exploiting the submissions of the volunteer coders on the kernel? At which point you're rejecting the Free Content idea that I think Wikimedia sees as being key to the project; certainly being involved in the Free Software community before Wikimedia existed colors my views on this matter.
Someone proposed making a translation dictionary from the English Wiktionary, but the problem was that if you take one line ("apple: tuffieħa) from ten thousand articles, the attribution required is larger than the text you borrowed. Wikidata suffers the same problem; any sort of mass use is likely to copy (probably uncopyrightable) text/information from thousands of separate items.--Prosfilaes (обговорення) 22:28, 14 February 2019 (UTC)
As far as I know Linux wasn't part of WMF. Every word can be framed 'emotionally loaded', but be assured that I meant to express the dominant meaning of 'exploit', whether someone else would go along with or confirm my suspicions (because that's what they are, nothing more, but certainly nothing less) or not. Every sentence – mine, yours – expresses some personal affection, that is no reason not to talk. The idea of Free Content becomes contorted when a Foundation that is established to promote Free Content suddenly would start to sell Free Content, and I cannot but sense that that is what will turn out to be the goal of Structured Data. It really only takes a few people to get implemented a tool that will serve first and foremost their personal interests – hat tricks like that are not rare and every growing organisation is prone to corruption. Convince me otherwise, the communication on the subject so far has not. Every apple within the project can without any legal problem be connected to every tuffieħa, and a dictionary can easily be compiled on Wikibooks, but indeed selling those same apples requires a special kind of salesmanship that I personally would not recommend to WMF. Jürgen Eissink (обговорення) 23:19, 14 February 2019 (UTC).
@Prosfilaes: The "oh we cannot expect attribution" is a weird argument to justify turning CC-BY text into CC0 text, because it simply is irrelevant in practice to Commons. On this project 99% plus of files only ever have one person editing the descriptions, dates or author entries. Even then, it may well be that it is not the editor than needs attribution, but the off-wiki source where the metadata or text came from. You cannot set up a project that harvests images and texts from the public, with an unambiguous legal commitment to attribution, and then years later change your mind, waive a technical wand, and haphazardly declare that text might be reused as CC0 and freely sold on losing all chance of attribution. That really does seem to make the word exploit entirely accurate, though I would also encourage the use of copyfraud. -- (обговорення) 09:56, 15 February 2019 (UTC)
This seems inappropriately threaded. There's a big difference between the existence of CC-0 captions and the copying of material nominally under CC-BY-SA into the captions, and given the complexity of this thread, I think the latter should be pulled out into its own topic.--Prosfilaes (обговорення) 18:00, 15 February 2019 (UTC)
The first Free Content foundation, the Free Software Foundation, sold Free Content from day one, and it's generally in Free Software circles considered entirely reasonable for organizations to raise a little money by selling copies of their Free Content, provided it's not done in a way to make it proprietary. Now that the Internet has become so dominant, few see any point in doing so. Linux is part of the history of the WMF, with the success of the GNU project and Linux offering the basis for the idea that a bunch of people working under Free Content licenses could produce something like an encyclopedia.
A dictionary can't be easily compiled on Wikibooks while following the CC-BY-SA, because including the histories of 50,000 entries or links to 50,000 entries is technically difficult. But if a book is on Wikibooks, then by the clear intent of the CC licenses that Wikimedia uses and the GFDL that Wikimedia used from day one, the book can be sold by all and sundry. You have a right to feel about that as you will, but if that's what you mean by

exploit, I think you missed the history and culture of the project from the start.--Prosfilaes (обговорення) 00:18, 15 February 2019 (UTC)

That's not what I meant, Prosfilaes. Maybe my words don't suffice for you to grasp what I wanted to say, but I can not be more clear than I already was. I'm leaving Commons now. Jürgen Eissink (обговорення) 00:49, 15 February 2019 (UTC).
TBH, even I'm still waiting to see more stuff deployed before "throwing the structured commons baby", they should've been clearer when presenting this thing. I remember some WMF guys putting some effort in differentiating "captions", "descriptions" and "filenames" (oh no no no, they are not descriptions, this is a whole different thing blablabla). Now, when captions are already in Commons... everyone has (apparently) assumed these 'captions' are the very same thing a description is (maybe without wiki markup?) just... under a CC0 license. There are even talks about bot-license-washing (!) the copyright of our descriptions claiming "too short". Why didn't they start there? Strakhov (обговорення) 21:10, 14 February 2019 (UTC)

Template:Countries of Europe[ред.]

Hello. Template:Countries of Europe. How can I change the alphavetic order of a country? Xaris333 (обговорення) 21:29, 13 February 2019 (UTC)

@Xaris333: You should probably edit Module:Countries or one of its subpages. What change are you going to make? 4nn1l2 (обговорення) 06:20, 14 February 2019 (UTC)
@4nn1l2: North Macedonia should change place in greek language. It must be after Belgium. Xaris333 (обговорення) 14:55, 14 February 2019 (UTC)
@Xaris333: ✓ Виконано Special:Diff/339025737. 4nn1l2 (обговорення) 15:12, 14 February 2019 (UTC)
Thanks. Xaris333 (обговорення) 15:13, 14 February 2019 (UTC)

Keyhole Markup Language[ред.]

Is it still imposible to upload kml files into Commons? In some NL Wikipedia articles I use Google my Map links. example: nl:Buurtspoorwegen van de provincie Brabant. It works fine, but if I die and my Google account is cancelled, all these links disapear. I saved all my kml files, so in theory someone can reload them on his Google map and remake the links. A lot preventable hasle.Smiley.toerist (обговорення) 22:56, 13 February 2019 (UTC)

@Smiley.toerist: Yes, and I don't think it will ever come given that we now have Geojson support. You can now replicate this on commons alone (compare e.g. Data:Bannister Street, Fremantle.map for a very simple example). http://geojson.io helps with creating (drawing) the data from scratch and there seems to be quite a bunch of free online KML-to-Geojson out there. Wikivoyage (at least the en: edition) makes heavy use of these through mw:Extension:Kartographer, compare e.g. the dynamic map at the beginning of voy:en:Saint_Petersburg. I don't know if the kartographer extension has been enabled on any of the Wikipedias yet, though. --El Grafo (обговорення) 09:30, 14 February 2019 (UTC)

February 14[ред.]

Removal of watermarks, watermarks being within scope[ред.]

I thought it was permissible to simply remove a watermark from an image uploaded with one of our compatible licenses. But it looks like Commons:WATERMARK is only a proposed policy/guideline and I'm having trouble finding something definitive. To me, if we cannot remove them, images with destructive watermarks should simply be deleted, but I cannot find where anything about this is written. Of course, enwiki's image use policy forbids such destructive watermarks, which is perhaps why I thought that was the case here, too... — Rhododendrites talk |  01:44, 14 February 2019 (UTC)

While COM:WATERMARK isn't policy, you can work out something pretty similar from COM:OVERWRITE and COM:EDUSE. Under COM:OVERWRITE, removing a watermark will generally be a minor improvement, so the cleaned image can be uploaded over the watermarked one, but if someone objects then you should upload under a new name. Under COM:EDUSE, if a watermark is so disruptive as to make an image unusable (or useless given other images we have of the subject), it can be deleted. I think the major difference from COM:WATERMARK is that promotional but non-destructive watermarks are not usually a cause for deletion. --bjh21 (обговорення) 09:54, 14 February 2019 (UTC)

Do we have a tag to mark text that needs cleanup?[ред.]

When I scan a document, or clip a newspaper article I add the raw OCR and duplicate it as Annotated text where I do cleanup and add wikilinks. I used to not add the text here, but to Wikisource, but many were deleted as not meeting the standard for Wikisource notability if they did not have a corresponding English Wikipedia entry. So do we have a tag to remind me to go back and do another round of cleaning up the text? See: Alma Francis wed in the Los Angeles Times on April 11, 1919.jpg as an example. RAN (обговорення) 03:21, 14 February 2019 (UTC)

(Edit conflict) @Richard Arthur Norton (1958- ):, you could add WikiLinks like "w:en:Random", "w:vi:Ngẫu nhiên", "w:nl:Willekeurig", Etc. Or probably as "[[w:en:Randomness|Random]]", "[[w:vi:Ngẫu nhiên|Ngẫu nhiên]]", "[[w:nl:Willekeurig|Willekeurig]]". Otherwise you could link to Wikimedia Commons gallery pages and categories in the form of [[:Category:Houses in Coshocton County, Ohio|Houses in Coshocton County, Ohio]] which would generate Houses in Coshocton County, Ohio. Furthermore links to Wikimedia Commons galleries don't require any such mark-up, only Canada, Taiwan (The Republic of China), Paris, Etc. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 08:02, 14 February 2019 (UTC)
Thank you! But I was looking for a category or other tag that reminds me that the OCR needs more cleaning. The text still has some gibberish. If I had a tag or category, I would be reminded to go back and continue cleaning up the text. RAN (обговорення) 13:53, 14 February 2019 (UTC)
So create yourself a hidden personal category for this purpose. - Jmabel ! talk 16:44, 14 February 2019 (UTC)
On the Commons side, it might be worth asking whether transcribing and annotating text is inline with project scope and What Commons is not. Transcribing public domain text from a .jpg is probably ok, while annotating, wikilinking, etc risks creating essentially a shadow Wikisource/Wikipedia. On the Wikisource side, I don't see why published newspapers articles would conflict with Wikisources's Deletion policy, What Wikisource includes, or Wikisource for Wikipedians ("Wikisource does not use notability as a basis for inclusion. Instead, professional publication is necessary for a work to be added to Wikisource."), although casual viewing of Wikisource:Proposed deletions suggests they're somewhat more prone to delete rather than improve incomplete or problematic scans and transcriptions. --Animalparty (обговорення) 20:36, 14 February 2019 (UTC)

Analphabetism on Commons[ред.]

There are a lot of people who don't know what capital letters, full stops, commas, etc. are for. Very basic things. So what to do with edits like this? Fixing it requires some effort for someone who uses Latin alphabet and I am rather lazy. Just revert it, especially that the caption is not too descriptive? --jdx Re: 05:37, 14 February 2019 (UTC)

  • In this case, I'd revert it. It's as if someone had written "barbara durer" as the caption in English: probably worse than nothing. - Jmabel ! talk 06:01, 14 February 2019 (UTC)
Probably "durer's barbara" given the case ending, but still not too useful. By the way, "analphabetism" is a semi-esoteric word in English (my spell-check doesn't recognize it)... AnonMoos (обговорення) 18:15, 14 February 2019 (UTC)
*cough* illiteracy *cough* --HyperGaruda (обговорення) 21:16, 14 February 2019 (UTC)
Thanks for the clarification, AnonMoos. Russian is probably not even one of my 10 best languages; I suppose any time I remark on something in Russian it should be taken with not just a grain of salt but a pound of salt. - Jmabel ! talk 02:23, 15 February 2019 (UTC)
@Jmabel: My opinion is the same, so I have just reverted the changes. @AnonMoos: Spellchecker in my Firefox also doesn't recognize it. But at least one dictionary defines it (and at least one doesn't). Enwiki redirects "analphabetism" (and "illiteracy") to "literacy" and says inability to do so is called "illiteracy" or "analphabetism". Here, in Poland, we say "analfabetyzm". --jdx Re: 03:47, 15 February 2019 (UTC)
Also defined as synonymous with illiteracy at wikt:analphabetism; see also fr:wikt:analphabétisme.—Odysseus1479 (talk) 04:27, 15 February 2019 (UTC)

Paintings vs. drawings[ред.]

Hi, I am trying to classify files from Getty by object type. I don't understand on what criteria some works of art are said to be drawings: File:Louis Carrogis de Carmontelle (French - Figures Walking in a Parkland - Google Art Project.jpg. The description says Watercolor and gouache, which is very much painting to me. Any idea? Regards, Yann (обговорення) 08:28, 14 February 2019 (UTC)

@Yann: Getty may consider that only oil-based paint may be used to create paintings, and that may be a minority viewpoint.   — Jeff G. please ping or talk to me 09:12, 14 February 2019 (UTC)
"Watercolor drawings" are a thing, although it's debated where the line between drawing/painting can be um, demarcated. There's a spectrum from colored pencil washes to ink and watercolor in combination to gouache (basically opaque watercolor). I don't know if the Getty's classification scheme is representative of other museums. --Animalparty (обговорення) 09:52, 14 February 2019 (UTC)
"very much painting to me" = [citation needed]. i see a google search is very much split on these phrases. it is a deep philosophical discussion of demarcation of medium: is it by base support medium, application technique medium, or binder medium? how much of the activity on this site is personal interpretation unhinged from scholarship? see also PRP. Slowking4 § Sander.v.Ginkel's revenge 13:24, 14 February 2019 (UTC)

Report copyright violation by a user?[ред.]

Hello, I haven't been active for a number of years, only occasionally make small edits and such. I just came across a copyright violation by a user here, it concerns several images at least. How do I correctly report these? --Caranorn (обговорення) 16:10, 14 February 2019 (UTC)

@Caranorn: If you are very sure and can use one reason for all files, you can also use the "Copyvio" Action in VFC.   — Jeff G. please ping or talk to me 17:20, 14 February 2019 (UTC)
I believe I have now completed my report. All images involved are minor derivatives of a single copyrighted original or a hybrid of several such hand drawn originals by a single author with minimal variation.~I will wait and see how the process goes and provide additional information if in my means and needed. --Caranorn (обговорення) 18:16, 14 February 2019 (UTC)

Notification of DMCA takedown demand - Video Call Santa[ред.]

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

Affected file(s):

To discuss this DMCA takedown, please go to COM:DMCA#Video Call Santa Thank you! Joe Sutherland (WMF) (обговорення) 23:22, 14 February 2019 (UTC)

February 15[ред.]

Moving files to wikipedia[ред.]

Hi, I understand there are tools to move files to Commons from Wikipedia, but I'm looking for the opposite, a tool to move files from commons to wikipedia. Know any? Thanks--Marc Lacoste (обговорення) 06:51, 15 February 2019 (UTC)

On Wikipedia, preference-->Beta-->file mover, mark the box, you get a tab above the picture on Wikipedia, "move to commons" @Marc Lacoste: ~ R.T.G 14:32, 15 February 2019 (UTC)
"move to commons" isn't what he asked. -- Begoon 14:50, 15 February 2019 (UTC)
Ah maybe... Commons files are already on Wikipedia, if that helps. I thought it said he understands you can move from commons to... but he didn't want..., apologies o/ ~ R.T.G 14:58, 15 February 2019 (UTC)

@Marc Lacoste: As far as I know there isn't a tool for this, because it rarely comes up and typically wouldn't be desirable. Can you give the specific example of what you are trying to do and why? - Jmabel ! talk 17:05, 15 February 2019 (UTC)

@Jmabel: Fair use of files which we can't host here on Commons because we have insufficient permission, like some 20th Century photos of persons who are no longer alive.   — Jeff G. please ping or talk to me 17:18, 15 February 2019 (UTC)
to backup exhibit models pictures in wikipedia before their deletion in commons like Commons:Deletion requests/File:ILA 2018, Schönefeld (1X7A5246).jpg--Marc Lacoste (обговорення) 17:19, 15 February 2019 (UTC)
@Jmabel: to transfer images to Wikipedia that are public-domain in the U.S. yet not in the country of origin, e.g. en:Category:Images published abroad that are in the public domain in the United States. This comes up sporadically during Good Article and Featured Article reviews. --Animalparty (обговорення) 20:31, 15 February 2019 (UTC)
Yes, those are examples of valid reasons to do this. I was mostly trying to work out whether Marc wanted to do one photo or a bunch. Sounds like a bunch. Also, sounds like in each case there is going to need to be a different non-free use justification written on the Wikipedia side, in whichever Wikipedia is involved, and it will be impossible in some (e.g. the German-language Wikipedia has more or less the same criteria as Commons in this respect).
Unfortunately, no, there is no special tool to do this. I suggest that you "rescue" the full-res versions of the images in question to your own hard-drive; probably ditto for the info on the file page, in case that is deleted before you get to upload to Wikipedia; and expect this to be a manual task unless you can either automate it yourself of convince someone with the relevant skills to put the time into it. (FWIW, even the tools to transfer from the various Wikipedias to Commons are mostly pretty crappy, in my experience.) - Jmabel ! talk 21:28, 15 February 2019 (UTC)

No, it’s not possible. From the FAQ: Can I use the FileExporter to export files to other wikis than Commons? — Speravir – 23:05, 15 February 2019 (UTC)

there was Commons:Bots/Requests/Commons fair use upload bot but need to motivate bot operator. could expand it's use for any file deleted in use at a wiki with a policy. Slowking4 § Sander.v.Ginkel's revenge 13:32, 16 February 2019 (UTC)

Related info on the Wikidata VP. –84.46.53.251 15:31, 17 February 2019 (UTC)

higher resolution of russion def minestry pic[ред.]

Is somebody able to upload the higher resolution of this file? Thx.--Sanandros (обговорення) 07:40, 15 February 2019 (UTC)

I tried, but it's a duplicate of File:MechanizedInfantryExercise2019-11.jpg. --ghouston (обговорення) 09:21, 15 February 2019 (UTC)
Yea thats fine. thx.--Sanandros (обговорення) 07:37, 16 February 2019 (UTC)
@Sanandros, Ghouston: It was deleted as a duplicate by Gbawden.   — Jeff G. please ping or talk to me 12:52, 16 February 2019 (UTC)

Ramiro A. Fernández[ред.]

Ramiro A. Fernández photo of Cuba, 1912

Hello, the above name is of a photographer who made popular collections of Cuban life photos, from about 1910s to 1950s. I cannot find exact information about his dates of birth or death. He is widely covered having collections in USA museums and many, many write ups, but no dates of birth and death and I read somewhere while I searched something about a Ramiro A Fernandez experience with the internet. I saw a something on the internet about a Ramiro A Fernandez using the internet himself. That would put this photograph in copyright so I just want to check if anyone is familiar with his story and ultimately if I should just tag it for deletion. ~ R.T.G 14:43, 15 February 2019 (UTC)

he appears to be a photo editor and collector, not photographer. so you may have a grab bag of unknowns. see also https://merrick.library.miami.edu/cubanHeritage/chc5260/. your item is tagged "The copyright and related rights status of this material is unknown."[14] you could make a case for "no known copyright"[15] Slowking4 § Sander.v.Ginkel's revenge 17:57, 15 February 2019 (UTC)
Ah okay. Don't know how I missed that! It's just this one I am aware of so I'll just change it to "unknown", thanks o/ ~ R.T.G 18:05, 15 February 2019 (UTC)
yeah, archival material is tricky, author = Ramiro A. Fernández was wrong. we could go through and mass upload this collection with the right status,[16] but would need a template like this one Template:Cornell Library no known copyright restrictions. i may get around to it. Slowking4 § Sander.v.Ginkel's revenge 18:20, 15 February 2019 (UTC)

uncategorised imports[ред.]

Which bot is in charge of marking uncategorised new files? It should be tweaked to patrol files from the new FileImporter feature as well.--Roy17 (обговорення) 19:29, 15 February 2019 (UTC)

If you mean adding files to subcategories of Category:Media needing categories then there is no bot - it is the upload wizard itself. Ruslik (обговорення) 20:39, 15 February 2019 (UTC)
Roy, you should ask for this on the talk page for the extension help. Or is this already known, Johanna? — Speravir – 22:59, 15 February 2019 (UTC)
Bots have done this previously, e.g., User:YaCBot, but I don't know if any is running currently. There will also be files that have no categories because somebody removed them. --ghouston (обговорення) 01:54, 16 February 2019 (UTC)

February 16[ред.]

Ringers in Category:Schinus terebinthifolia[ред.]

In looking for images of this tree species to add to an English Wiktionary entry, I found pictures of:

  1. A red-footed booby
  2. A surfer
  3. A smiling pilot
  4. A horse
  5. Hawaiian nene geese
  6. A highway overpass in Ft Lauderdale, Florida

Although there are a number of good images with recognizable Schinus terebinthifolia in them or that are clearly related in some way, there are far too many that were swept up with the on-topic ones from someone's flicker account because they had the botanical name in their filenames. I'm guessing that the photographer went on trips to Florida and Hawaii primarily related to the trees (they're a serious invasive threat to habitats in both states), and labeled all the images from those trips with the botanical name.

I'm busy enough at Wiktionary to be unable to spend time on this, but I thought I would bring this up so someone with more time might deal with it. Thanks! Chuck Entz (обговорення) 05:55, 16 February 2019 (UTC)

  • @Chuck Entz: Great find, thanks! I fixed one, five more to go. Likely much more than five, though, if this kind of multi-sided categorization error is widespread. -- Tuválkin 08:52, 16 February 2019 (UTC)

Urgent rename and re-cat[ред.]

Uploaded files have the wrong name (users can not find them easily). Urgent name change, as this is happening-now eurovision. Change all files uloaded by "DollyStyle" to "Dolly Style", and change the category as well accodring to same name. Or, is it quicker if I re-upload with new names and categories? --Janwikifoto (обговорення) 10:44, 16 February 2019 (UTC)

  • Do not reupload: any fix is better than that. Would be faster if you offered a link, too. -- Tuválkin 11:37, 16 February 2019 (UTC)
-- Tuválkin 11:41, 16 February 2019 (UTC)
  • Rename is better. As I will upload many more pictures of the group, and the new uploads will have the "correct" name. One name style is preferred. Re-upload and speedy delete opf the old ones is an alternative. Thanks, --Janwikifoto (обговорення) 21:34, 16 February 2019 (UTC)
  • @Janwikifoto: Please do not speedy-delete and re-upload to cause a filename change. If you wish to rename these files, then better add this to their filepages:
{{Rename|(new filename)| 4 |reason= Typo: Missing space}}
However be advised that other users may upload photos or other media of this band and there’s no requirement that those new files will have "Dolly_Style" in their filenames — and that then changing those filenames to add it would be against COM:FR. -- Tuválkin 10:12, 17 February 2019 (UTC)
Ah great, now I know how to tag name chane! Question - how do I "mass-tag" the maybe 60 files, in one operation? (re-upload wastes bandwidth, but saves my personal time). I am aware that others may upload under another name, but I only think about my own pictures now. I would not generally re-name another users file, unless the name was totally wrong, offensive, or anything such. These files could just as well have been named "Melodifetsivalen...." in the beginning, makes sense for thos looking for such files, and we can go on with other reasonale name variations. Question - if I had filemove rights, would it be a simple operation for me to change the names, in one operation? Thanks --Janwikifoto (обговорення) 10:35, 17 February 2019 (UTC)

Deletion statistics?[ред.]

I can't find it at Commons:Statistics, are there statistics of the number of deleted files available? Even better would be: Number of deletion requests, kept and deleted files. Gestumblindi (обговорення) 12:27, 16 February 2019 (UTC)

Another useful stat: percentage of DRs closed as deleted, per Admin.   — Jeff G. please ping or talk to me 12:47, 16 February 2019 (UTC)
Though it might be interesting, knowing that one person with sysop rights proportionately has closed twice as many DRs as Delete compared to the average, does not in practice mean much. Administrators are attracted to different types of maintenance task, and so one person attracted to simple copyvio based deletions will be highly likely to have a very high Delete rate compared to another attracted to complex debatable copyright cases.
Thinking through the meaningfulness of statistics related to individual administrators would take a fair amount of further research, and does not stop with proving that person A appears to Delete or Keep three times as much as person B. -- (обговорення) 12:57, 16 February 2019 (UTC)
I agree. My reason for asking is because on the German-language "Forum", a contributor wrote about a perceived increase in the number of deletions, and I now wonder about the actual numbers and trends. Gestumblindi (обговорення) 13:07, 16 February 2019 (UTC)
Certainly, that is a trend worth understanding and checking if the stats do demonstrate it. -- (обговорення) 13:09, 16 February 2019 (UTC)
even better, would be deletion nomination by admin, with keep / delete, or speedy delete versus undeleted. Slowking4 § Sander.v.Ginkel's revenge 13:26, 16 February 2019 (UTC)
Usually such things get reported at "Commons:Database reports", if they get reported at all, I do hope that more statistics will be collected. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 19:09, 16 February 2019 (UTC)
Had a look there, too, but haven't found any deletion statistics there either ("Previously deleted files" is just a report of new uploads of previously deleted files). Gestumblindi (обговорення) 19:25, 16 February 2019 (UTC)

strange category (given name)[ред.]

In the Category:Philip II of Macedon is a very strange given name category. I am not able to fix it. Can somebody correct it? Thank you. --DenghiùComm (обговорення) 21:40, 16 February 2019 (UTC)

  • Wikidata screwup. I'll contact them if I can't entirely fix it myself. - Jmabel ! talk 23:09, 16 February 2019 (UTC)

More personal data nonsense piped in from Wikidada[ред.]

(Sigh:)

  • Creator:Al Franken has is redlinked to "JEWISH/US" (sic!). I looked around at d:Q319084 and could not figure out whence this comes.
  • Redcat Category:De (given name) keeps being populated with people with the words "de" or "De" in their names in spite the fact that neither is really a given name, nor even, in most cases, a standalone name word.

Can we finally accept that Wikidata, in spite of the lavish funding and all the praise from bigwigs, is simply an unreliable GIGO machine whose flunkies cannot find their way out of the proverbial wet paper bag — and therefore we need to keep our hard researched and mantained data stored locally in a way (i.e., wikitext) our community can easily go on curating it? -- Tuválkin 10:27, 17 February 2019 (UTC)

This is Module:NationAndOccupation/nationalityLUT which maps єврейські американці (Q678551) (from P172) to 'jewish/US' and presumably throws that into {{Nationality/en}}. Most of which is on Commons side. Jean-Fred (обговорення) 11:08, 17 February 2019 (UTC)
Did Special:Diff/339405245 quickly − not ideal still ; someone better versed in the whole {{nationality}} setup should have a look. Jean-Fred (обговорення) 11:11, 17 February 2019 (UTC)

License for Munich Security Conference media?[ред.]

Today I uploaded media from www.securityconference.de to the 55th Munich Security Conference category, using the {{MSC}} template. This template references the imprint notice under [17], and the respective English version. I just noticed that both now return a ”page not found” message.

Does this mean that MSK no longer grants a cc-by-sa license on its media? Or that I should address my query to them?

Thanks for any comment. -- Renardo la vulpo (обговорення) 23:49, 16 February 2019 (UTC)

@Renardo la vulpo: Thanks for the notification. Please see the official requests at Template talk:MSC#Aktualisierung nötig.   — Jeff G. please ping or talk to me 16:07, 17 February 2019 (UTC)
A remark by Hasenläufer on the talk page resolved the problem: There is a new imprint page, and it still grants usage under a share-alike license. But since the {{MSC}} template is write-protected we would need an admin to make the updates. -- Renardo la vulpo (обговорення) 16:08, 17 February 2019 (UTC)
@Renardo la vulpo: Right, that's why I added {{Editprotected}}.   — Jeff G. please ping or talk to me 16:12, 17 February 2019 (UTC)

February 17[ред.]