Commons talk:File captions

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


I started this quickly based on the messages of @Keegan (WMF): on the Village pump. Feel free to expand etc. :) Jean-Fred (talk) 11:59, 11 January 2019 (UTC)

I think the information, that the caption is the same as labels on Wikidata should be in the introduction. Or do you think the majority of the Commons Users do not know what labels on Wikidata are? --GPSLeo (talk) 13:46, 11 January 2019 (UTC)
@GPSLeo: I added something − please have a look whether it is clear :) Jean-Fred (talk) 10:41, 16 January 2019 (UTC)

accessing captions[edit]

Is there a documentation on how to access those captions, from templates or lua? --Jarekt (talk) 18:06, 11 January 2019 (UTC)

Not yet. The documentation will be published when it's available, I assume on but I'll let you know. Keegan (WMF) (talk) 18:59, 11 January 2019 (UTC)
Added to the FAQ. Jean-Fred (talk) 10:42, 16 January 2019 (UTC)

Category captions[edit]

Why not extend these as "Commons:Category captions"? As category pages tend to be more similar to Wikidata instances than anything else. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 20:27, 11 January 2019 (UTC)

@Donald Trung: MediaWiki's categories system is a dead end. You can read more about the motivations for the project at Commons:Structured data/About. Jdforrester (WMF) (talk) 23:22, 11 January 2019 (UTC)
@Jdforrester (WMF): so shall we stop categorizing? Work through stuff like Category:All media needing categories as of 2018 does not make sense any more. How will structured data do the magic? --Herzi Pinki (talk) 10:26, 12 January 2019 (UTC)
@Herzi Pinki: In general, the Wikimedia Foundation staff don't tell community members how to use the wiki software. :-) If categories are working for you and the use cases you think are valuable, yes, you should keep using them. Structured data will let you add "depicts" statements to a file. The search system will let you find files with a particular combination of depicts statements (for example, you might want to find photos with both dogs and cats in them). This software is still being written, but will hopefully available soon, which may give you a better idea of what is involved. You can see provisional designs and community discussions about the software at Commons:Structured data and related pages. Jdforrester (WMF) (talk) 20:18, 12 January 2019 (UTC)
will there be something as caption-a-lot as replacement for cat-a-lot? best --Herzi Pinki (talk) 10:35, 12 January 2019 (UTC)
@Herzi Pinki: I don't know. Cat-a-Lot is a gadget. That means it is not supported by the Foundation, but by the Wikimedia Commons community. Hopefully the need for the gadget will go away if we have built a system that is useful for you to tag images appropriately. If, however, the community sees a value in adding a gadget to add depicts statements, that would be possible. Jdforrester (WMF) (talk) 20:18, 12 January 2019 (UTC)

MediaWiki's categories system is a dead end & In general, the Wikimedia Foundation staff don't tell community members how to use the wiki software - no comment. --Herzi Pinki (talk) 10:29, 16 January 2019 (UTC)

That's a red light to me, it's as if we (unpaid contributors/volunteer contributors) are the blind and the Wikimedia Foundation are those that can see, but rather than leading us they let us walk astray. I don't personally see it that way, MediaWiki's category system has a lot of untapped potential and when the "depicts" feature gets rolled out we should campaign for some "depicts" to be bundled with categories, for example Category:Eiffel tower 🗼 (I think that that's the Tokyo tower, my keyboard has odd suggestions sometimes) should automatically add the "depict" statement for the Eiffel tower, there should be a way to embed such automatic tagging, but I have the impression that the Wikimedia Foundation is underestimating the usefulness of the infrastructure built by the volunteers over the years. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 10:57, 16 January 2019 (UTC)
@Herzi Pinki: This is not necesarily a contradiction: I think Jdforrester means that the MediaWiki’s categories system is a technical dead end: we can’t make them evolve much further, and we are trying to make it do things it cannot do well (for example intersections) − thus the WMF is building tools (here: SDC and depicts) that is made to support some of the goals we have. At the same time, the WMF is not « telling community members how to use the software » − if we decide depicts: sucks and we want to continue using categories, that’s our prerogative.
To me this is all similar to Templates. The templates language (and ParserFunctions) were also a dead end − we were doing with them things they were not made for (like, eg, building structured lists of thousands of monuments − the template system would eventually give up when the list was "too long"). That’s why the WMF introduced Lua for templates − at the same time, they did not tell us how to use them. Plenty of people (me including) still use good-old parser functions ; but Lua did allow us to build things that old-templates could not really support well. Jean-Fred (talk) 11:12, 16 January 2019 (UTC)
Improvements could be made, just see "User:Multichill/Next generation categories". --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 11:56, 16 January 2019 (UTC)
I’m well aware of that page (and have been for years ;-)) − and I have defended Commons category system many times in the past (see eg this post in French from 2013). You’re saying that « improvements could be made » − in theory yes, but in practice, is that technically easy or possible at all, does the very design and architecture of MediaWiki’s category feature allow us to make such improvements? Sometimes it’s better to design something else entirely. It’s 2019, and we can now leverage on the Wikibase software and all of Wikidata to design organisation systems. Jean-Fred (talk) 12:24, 16 January 2019 (UTC)
(This is all touched upon in Commons:Structured_data/About/FAQ#Will_Commons_still_have_categories?_Will_Commons_categories_disappear? Jean-Fred (talk) 12:36, 16 January 2019 (UTC))

@Jean-Fred: If categories are a dead end (which I can understand to a certain point), and there is a successor functionality with SD, why should I continue to categorize? Why should anybody continue to categorize? I was willing in my first statement above to immediately stop with categorizing. There is no sense in doing things twice. My question is not will categories disappear? (I read the linked FAQ before), but will it still make sense to put effort into categorizing?. Well, it is a dead end, whatever the community decides about the usage of categories, it is wasted effort. But then WMF returned the ball to the community instead of bravely presenting the transition strategy. BTW, using the term we always is a bit disturbing, when features are imposed on the community by the foundation. --Herzi Pinki (talk) 18:17, 16 January 2019 (UTC)

@Herzi Pinki: I think « Categorizing » is too much of a multi-purpose and multi-faceted tool that we can make sweeping statements like that :) I do believe that SD will eventually be much more useful for certain types of things − for example, I do believe it won’t make sense anymore to categorize things in St. Stephen's Cathedral (because adding a property depicts:St. Stephen's Cathedral (Q5943) will be much easier) ; nor will it make sense to maintain category trees like Exterior of St. Stephen's Cathedral, because we can express this sort of thing much better (using qualifiers, other properties − depends how we go). But eventually is an operative word here − how long will it takes for SD to reach that level? For the community to build helfpul tools and worflows around it? − eg: things like Cat-A-Lot, Hot-Cats, or VisualFileChange are at the moment powerhouses for curators ; it will take powerful alternative tools to work with SD to convince curators to switch. Also, populating SD will take some time as well − I’m sure there will be bots to do that (among other things by building upon the current categorisation!) but that will take time too.
Also, I have to say − I don’t understand how at the same time you seem to regret that features are imposed on the community by WMF (a statement I would disagree with, but I certainly understand the position) and wish that the WMF would design a transition plan for them to implement and for the community to follow. That sounds like something that a lot of users here would find outrageous. :-)
Jean-Fred (talk) 11:26, 21 January 2019 (UTC)
@Jean-Frédéric: thanks for your answer. SD was promised to me some four years ago as a replacement for categories by WMDE staff, when I complained about the tremendous effort to do the categorization for things like WLM (now WikiDaheim). Now it is late but it seems to be there. Let's embrace it. User:Braveheart pushes SD for Wikidaheim, stating that it might make things easier. I have no idea how this will work, how this will be accepted and understood by novice uploaders, how this will be smartly integrated into various upload tools and what back end work has to be done. There is no tool support right now. Doing categorization and SD on the large for sure does not make things easier. Using SD just as a gimmick for those uploaders that want to use it, will not be a pilot for SD, but only add to complexity of the upload processes and the back end processes. I'm a bit scared, that SD will break Wikidaheim. Categorization is too complicated for many people, even after years. Wikidata is even more complicated for many people, on the large it is not used by uploaders. SD will be similar to Wikidata, but unlike Wikidata SD will be part of the user interface during upload. Sadly there will be no magic. best --Herzi Pinki (talk) 13:47, 21 January 2019 (UTC)
See Commons:Structured data/About/FAQ#How can the information in Commons categories be used for structured data on Commons?. I've always thought that a data-tagging system would work better than categories. However, I'd like to know what license my edits adding "depicts" tags will be under; the editing interface does not say. A copyleft license like the Open Database License would be fine. HLHJ (talk) 01:37, 20 May 2019 (UTC)
@HLHJ: Depictions are structured data. Per the text at the bottom of every page on Commons, "All structured data from the file and property namespaces is available under the Creative Commons CC0 License". And even if this weren't explicitly stated, adding simple depictions would likely be uncopyrightable in any jurisdiction: ideas and facts cannot be copyrighted, and thus are public domain. You can't copyright or license simple facts or statements like "sky = blue" "number of sides on square = 4", or "depicts = William Shakespeare". --Animalparty (talk) 05:46, 20 May 2019 (UTC)
@Animalparty:, thank you for the clear answer. It would be great to include it in the GUI. While you cannot copyright simple facts, in many jurisdictions (including the US one that Wikimedia tends to prioritize) you can copyright a database of facts, as Open Street Map has done. A lot of the facts on Wikidata are taken wholesale from the corresponding copyleft Wikipedia articles; no idea of the legalities of this. HLHJ (talk) 18:25, 1 June 2019 (UTC)
  • @Donald Trung, Jean-Fred: In response to the original question for this section, the current blocker (as I understand it) for "why captions can't be extended to categories" is that at present a wiki-page can only be associated with an entity on a single wikibase. Which wikibase can vary from namespace to namespace. (So for example :File: pages are now associated with an entity in the SDC wikibase, whereas :Category: pages can be associated, via a sitelink, with a entity on Wikidata).
If a category is presently associated with an item Wikidata, then {{Wikidata infobox}} currently does a very good job of presenting a "category caption" (ie the Wikidata description). But, of course, the Wikidata community at present is only allowing Wikidata items for about a quarter of Commons categories.
According to this response on Phabricator [1] (Jan 30, 2019) it is on the radar that WMDE may work on the "single wikibase" issue this year -- primarily so that external (non WMF) wikis will be able to associate pages with entities both on Wikidata and on their own Wikibase. This should remove a key blocker against categories having their own items on the SDC wikibase, in turn allowing 'category captions' to become possible, and detailed descriptions of categories in terms of SDC entities. But if this is desired, then the use-case will need to be emphasised to make sure it is on WMDE's radar.
For the meantime I have been experimenting with a simple template, {{Main subject}} that can be placed at the top of a category, to describe what the category represents in terms of a combination of Wikidata items. So far I have added it to about 150 "old maps" categories, as I have happened to be editing them. The advantage of this template is that it should give a fully-internationalised clue to what the category is about (to the extent, anyway, that labels in appropriate languages exist on the corresponding items on Wikidata); and it is reasonably straightforward with SQL to see which pages in a category tree have the template; and then to use a script to scrape all those pages to retrieve their stated combinations of Wikidata items. Of course, this is a lot more roundabout that just being able to access the information from a SPARQL query; but for the moment it would seem to be the best that is possible.
Personally I strongly believe [2][3][4][5] that the category system is important and has a substantial future ahead of it, and well as being possibly the most important source of metadata we currently have for images, that will be essential for populating SDC.
The fundamental point about category pages is that they provide a ready-made pre-baked view of content that can be curated more readily and to a much greater extent than a page of search results. That is something I believe Commons editors will continue to value, and why they will continue to work on categorisation. One should never underestimate what motivated people can do, but I believe approaching this with SDC will be not easy. To start with, category results are available instantly; search results, particularly involving complex criteria or broad sets, will take time. That's before you even get into search results involving Wikidata hierarchies ("pictures of animals that...", "pictures of people who..."), which have thrown up such major problems that the team have backed away from this for the time being. With categories you also get a human judgement of how much to put into a category -- possibly combining quite a lot of specifics into a group that is "right-sized" and makes sense; or, alternatively, what makes sense to split apart, and what kind of splits and sub-categorisations make sense. Some of this you can do in search with auto-suggestion of refinement facets, which can also add very valuable flexibility (let the user choose what they want to see), but it's not straightforward for a system to know how to coalesce together the products of any possible refinement into sub-groups that make sense. There's also of course the issue that categories allow considerable curation and control of presentation -- eg what order to best present images, which can be quite subtle but very important, particularly for images drawn from a particular collection or set of works; which images to defer to sub-categories, away from a primary category; /how/ to split up the images most sensibly; and, of course, the ability to introduce and contextualise the category with appropriate explanatory wikitext. None of this do I see Commons editors giving up lightly, even once there is sufficient data in SDC to make search dependable (which itself is no small ask). So any idea that SDC is going to 'bury' categories; or that categories should be written off as 'end of life', so no development effort should be expended to accommodate them, seem to me to be way off beam. Instead I suspect we shall things go through the classic stages of thesis (we've thought of a new system that will solve everything and be wonderful), antithesis (some things it can't do, and other things are really hard), and finally synthesis (both systems have things they can be really good for, and working them together can make them better still).
But I do think a key required step towards this will be to establish wikibase items for categories, that can be queried through WDQS-like queries. Jheald (talk) 19:47, 2 June 2019 (UTC)
Also pinging @Herzi Pinki: Jheald (talk) 19:51, 2 June 2019 (UTC)
Thanks Jheald, I fully agree with your comment. --Herzi Pinki (talk) 20:09, 2 June 2019 (UTC)
Ah, thanks for explaining. Though I hope that in the future simply adding a media file to a certain category would automatically add file captions to it essentially making file captions and existing categories work in harmony, but this is all still very much a work in progress. Whoops, this was meant for file depicts, not captions. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 21:52, 2 June 2019 (UTC)

File captions and Javascript[edit]

A main reason disabling or blocking Javascript can break some functionalities, but do they add or edit media file captions without requiring it?  HarvettFox  96   03:05, 12 January 2019 (UTC)

Captions are structured data[edit]

Usually, we tend to be more precise. There is no such thing as a structure in a caption. It is plain text with little constraints (except the length and the plainness). To be honest, I would prefer captions to be seen as a single item in the structured data (Structured Data for Commons), part of structured data or something similar --Herzi Pinki (talk) 10:20, 12 January 2019 (UTC)

Good point, the phrasing was a bit misleading. The captions content is indeed unstructured ; the caption as a container is structured (as multilingual) User:Pigsonthewing clarified that in the FAQ − hope it’s clearer :)Jean-Fred (talk) 15:39, 14 January 2019 (UTC)

Styling section[edit]

@Speravir: Both gadgets MediaWiki:Gadget-Collapse-Captions.js and MediaWiki:Gadget-Compact-Captions.css can be edited and improved − they were made that way because at the time of their creation, that seemed to be the best way to do it (based on other folks posts). I’m more than happy to implement any changes to the gadgets :) Jean-Fred (talk) 10:53, 16 January 2019 (UTC)

No, Jean-Fred, the MediaWiki namespace can only be edited by administrators. — Speravir – 21:54, 16 January 2019 (UTC)
Sure (actually, by interface administrators) − which is why I said that I’m happy to implement changes on behalf of others. Feel free to drop a {{Edit request}} on the talk page of any gadget and ping me :) Jean-Fred (talk) 22:27, 16 January 2019 (UTC)
Ah, just saw your other ping on the VP − will get down to it soon :) Jean-Fred (talk) 22:28, 16 January 2019 (UTC)

Two bits of information[edit]

Hullo, I wanted to add two things to the file captions page but hesitate to edit the page directly. I think the following additions would be helpful:

  1. In the “How is this different than descriptions” section, say “As such, captions will be easier for search algorithms to parse and will be searchable through the API....” instead of “As such, they will be searchable through the API....”
  2. In the “Why are languages X Y and Z displayed for me?” section, say “The languages displayed are the ones listed in Babel boxes on your userpage and the languages added to your browser’s language configuration” instead of “The languages displayed are the ones listed in Babel boxes on your userpage.”

Take them, leave them, or adapt them as you like :) Abittaker (WMF) (talk) 22:04, 22 January 2019 (UTC)

hidding the captions with gadget does not work anymore[edit]

The hiding of caption (both gadgets checked, FF), does not work for me anymore. I can toggle between collapsed and expanded, but the space just gets empty and does not disappear. So instead of having the file captions box, I do have white-space of the same size. Played around a bit with css, but could not fix. When collapsed, the box should not consume more space as needed for the uncollapse button. Need help. --Herzi Pinki (talk) 10:02, 24 January 2019 (UTC)

works again. thanks to the one who fixed it. --Herzi Pinki (talk) 16:34, 3 February 2019 (UTC)
Checkmark This section is resolved and can be archived. If you disagree, replace this template with your comment. Herzi Pinki (talk) 16:34, 3 February 2019 (UTC)


Found Commons:File_captions#What_are_the_benefits_of_captions? All bullets are for internal purposes, but filling in infoboxes is not. So does this mean that captions must be encyclopedic in a way that they can be automatically used for display in infoboxes? I have upgraded the campaigns and the interface to them in my responsibility to automatically generate captions from the structured data we already have in the table rows. This will generate a caption like:

Installation Wandgestaltung im Forum der NÖ Versicherung in St. Pölten (ID: 588), Nikolaus Gansterer (2007), St. Pölten (Regierungsviertel), St. Pölten

which will help to search and find by common search terms like the place, the year, the artist, but it will not read well in infoboxes. So what is the purpose of caption: Support people browsing Commons to find the right image, allow multilingual captions in parallel or (really?) provide an encyclopedic description generally usable in infoboxes? --Herzi Pinki (talk) 16:50, 3 February 2019 (UTC)

silly question? --Herzi Pinki (talk) 23:49, 14 February 2019 (UTC)
Captions are meant primarily for points one and two, searching and multilingual support. This will become more evident when new search is available later next month (as currently scheduled). As for other wikis reusing captions, that is entirely up to individual wikis. Importing captions is certainly technically possible. Keegan (WMF) (talk) 16:33, 15 February 2019 (UTC)
thanks and sorry @Keegan (WMF):, if it is up to individual wikis to reuse captions on community consent on individual wikis e.g. in infoboxes, we have to know in advance, whether there is any e.g. German speaking wiki (,,, ...) doing this and then we have to make German descriptions that read well in infoboxes for all images. If we want to keep the possibility to use captions for display in infoboxes, all captions in all languages must read well in infoboxes, otherwise there is no individual choice for individual wikis. I just wouldn't promote the use case of filling infoboxes (as done in Commons:File_captions#What_are_the_benefits_of_captions?). best --Herzi Pinki (talk) 18:58, 15 February 2019 (UTC)

Disabling/Hiding File captions[edit]

Hi, Is there a way to hide or disable File captions from images as well as from the upload box ?, I've always used descriptions and categories from images so for me personally I have no use for this and truth be told it'll be very unlikely I will ever see or have a use for it,
Many thanks, –Davey2010Talk 21:15, 5 February 2019 (UTC)

A disabling section should've been added as not everyone is going to read it all - I navigated to the bottom assuming there were disabling options, Ah well disabled anyway. –Davey2010Talk 21:22, 5 February 2019 (UTC)

Should Commons:Captions redirect here?[edit]

Given that Captions are now, by default, everybody's business (on all media beyond just audio/video), I think Commons:Captions should redirect to this page (or even replace the page name as a primary topic) rather than currently redirecting to Commons:Timed Text. As structured data captions are still new and controversial, and kinks are still being worked out as new editors discover them, we should make it as easy as possible for people to quickly find out about using, them including the use of relevant shortcuts, redirects, and visibility (e.g. COM:CAP). Thoughts? --Animalparty (talk) 02:37, 14 February 2019 (UTC)

IMO it is a good idea, but perhaps changing Commons:Captions to a disambiguation page would be better. --jdx Re: 04:41, 14 February 2019 (UTC)
✓ Done converted to disambiguation page. Jean-Fred (talk) 09:14, 14 February 2019 (UTC)

Best practices?[edit]

Is there guidance on how captions should be composed/structured? Recommendations on what to include and what not? Hypothetical captions for the same same file could could be "A chair", "Photograph by Jack Smith", "Photograph of a wooden chair", "A wooden chair with a broken leg photographed by Jack Smith in Sweden on June 13, 1985. There is a rose painted on the back of the chair, and the chair sits in a garden next to a brick wall", etc. I'm not saying that any of these captions are better or worse than the other. And of course, no caption will be equally useful in all contexts. I can picture more meticulous users adding info that is true yet irrelevant (non-notable photographers, undue emphasis on minor details, etc.), other users adding frustratingly vague captions like "trees", "Russia in 1990", or "Photo by Bob Smith" (especially during bulk uploads), and trivial edit-wars. Perhaps we could take a few tips from en:Wikipedia:Manual of Style/Captions, (especially tips for describing pictures) and the spirit of en:Wikipedia:Image dos and don'ts to create some simple guidelines, free from gobbledygook about API, HTML, LUA, etc. (we should not expect users to know or care about such elements), if for no other reason than to have a reference point for disagreements? --Animalparty (talk) 05:09, 14 February 2019 (UTC)

Other issues for consideration: is it desirable or extraneous to specify media/type of work (i.e. Photograph of X, Painting of X, Video of X)? Should captions of organisms always include scientific names ("a lion cub in Kruger National Park, South Africa" vs "juvenile Panthera leo in Kruger National Park, South Africa"). Or does it not really matter in the long run? --Animalparty (talk) 06:14, 14 February 2019 (UTC)
There is no guidance as of now that I know of. You’re right that this help/FAQ page grew quite technical (reflecting the interests/questions raised) and is not that helpful for guidance on what to put into captions − it’s somewhat touched upon (as derived from the character limit) but could use clarity. I’d for one welcome something like that :)
(Digging around − did we have guidance on old-style file descriptions? Can’t find anything right now).
Jean-Fred (talk) 09:20, 14 February 2019 (UTC)
Added a stub at Commons:File_captions#What_makes_a_good_caption?. Jean-Fred (talk) 11:13, 14 February 2019 (UTC)
A Brighton & Hove bus (oh shit can't have wikitext)
Scania N270UD OmniDekka (oh shit, still no wikitext!)
You don't want to be stuck in one of these for 12 hours with your mother-in-law
Double-decker busses are a common mode of transport in the United Kingdom
The vehicle, 5 minutes before it plummeted into a ravine

As nobody seems to, I'm going to state the obvious: file captions are a complete and utter failure.

First the licensing problems, which still haven't been solved for existing captions. And now we get complaints. Now the licensing issues at least could be solved, it will probably hurt, but it's possible. But that won't take away that captions are completely useless. Here are the supposed benefits of captions from the project page:

  • searching for and finding captions Pictogram voting comment.svg Comment Pointless and already possible with descriptions.
  • filling in infoboxes Pictogram voting comment.svg Comment Captions are not allowed to contain wikitext, so it's nigh worthless for this purpose. Wikidata already has options for this and is more suited for that purpose as it isn't restricted to one caption per image.
  • query files for missing captions in a given language Pictogram voting comment.svg Comment What, are we collecting trading cards? "this card is useful because you can trade it", so it's useless.
  • building lists for translation of important files needing a caption localized for a project or campaign Pictogram voting comment.svg Comment So in other words, useless.

Captions have no purpose whatsoever. As Animalparty laid out above, there is no single caption that will always be useful for a file.

But, good news everyone! The solution is obvious, and I'm in a good mood, so I'll share it! Ditch file captions and replace them with what they were obviously meant to be: descriptions for the visually impaired. Such descriptions will:

  • Nearly always have to be written from scratch, eliminating license issues with copied descriptions.
  • Be much more likely to be PD-ineligible as they will leave less to the imagination.
  • Improve accessibility to Wikipedia for the visually impaired - AN ACTUAL USE CASE.
  • Improve searchability of images in multiple languages - HOLY SHIT ANOTHER USE CASE.
  • Have far less need for any wikitext.
  • Will universally apply to an image, regardless of context.
  • Contain the kind of metadata you want in Wikidata-like structures, that is, factual information.

You're welcome! - Alexis Jazz ping plz 15:35, 14 February 2019 (UTC)

(Look, I’m not exactly happy either with how the whole file captions thing is going − I’m just trying to stay positive and improve the stuff. I do understand your frustration with file captions − I’m not saying you should not be, nor do I mean that my way is better. What I mean by this preamble is that we are probably more in agreement than it would seem :-) )
That said: the list of supposed benefits that you pick apart is one that I more less threw together (Special:Diff/334382944 & Special:Diff/334383672) based on some things that Keegan said at some point. It’s not really bulletproof use cases, or well-thought-through formulations, or anything really but what I threw in in this FAQ in whatever time I had.
Now, for the use-cases you are listing: some, at least I believe, are actually things that captions may/will cover (at least based on my understanding):
  • Improve searchability of images in multiple languages → that’s actually quite what I meant by searching for and finding captions (which you deemed pointless ;-) )
  • Have far less need for any wikitext. → well, that is certainly true of captions :)
I would disagree that “querying files for missing captions in a given language” is useless − as I recall it’s actually a use case that had been specifically requested by French-speaking users at some point: users looking to identify files in a category tree that needed translation to French. I tried providing some CatScan magic to make it happen and it hardly worked (for example, it only worked with templates {{En}}-like templates ; not with eg {{Mld}} which was popular at the time).
Cheers, Jean-Fred (talk) 18:33, 14 February 2019 (UTC)
@Jean-Frédéric: alright, still, searching regular descriptions already works. We don't really need captions for that. Descriptions for the visually impaired would be different. For example, look at File:R federer.jpg. For the visually impaired, a description would be something like "Roger Federer, torso and face, wearing a blue shirt, hitting a tennis ball with a red-and-black tennis racket, the ball and racket shown out of focus in front of him". This includes a host of keywords not typically found in descriptions and greatly helps when searching for images. It is also much less likely to be copyrightable, as it is nothing but a list of facts. And it could be used immediately to fill the "alt" field for images on Wikipedia and other projects, so there is an actual use case. - Alexis Jazz ping plz 20:31, 14 February 2019 (UTC)
Pinging @Keegan (WMF), SandraF (WMF). I may well propose this. Any comment? - Alexis Jazz ping plz 20:34, 14 February 2019 (UTC)
Thanks for the answer @Alexis Jazz: :)
Regarding search − we do have full-text search, but it will necessarily search through the entire page contents, including categories and license templates and all (to be fair, in most cases that’s probably fine), and as far as I know it’s not possible to do it per language. So for example, searching for “kop” (which, or so I read, means “cup” in danish, “head” in dutch and “kick” in czech) may not return relevant results.
Descriptions for the visually impaired is indeed definitely something that we should provide (that’s phab:T21906) and should totally belong on the SDC roadmap − thanks for raising that.
Jean-Fred (talk) 23:03, 14 February 2019 (UTC)
@Alexis Jazz: Structured data on Commons has something like nearly a dozen distinct features to finish designing, building, and implementing over the course of this year. Have a look at the stack of engineering work involved[6]. Captions are but a single feature of the entire suite, and one that had to be introduced first for a plethora of reasons but the primary driver is deploying the underlying software architecture that will make this whole thing work, namely federated Wikibase and multicontent-revision controlling. Now, could some things of the release of the feature gone better? Absolutely. I and we can learn from the deployment and aim to make things better for the next one. All of this is to say, you are welcome to continue to vent your frustrations and concerns. There's certainly stuff that's not wrong in the criticism. I would encourage you to consider that this is a mammoth software project, being released incrementally, and consider that there is time to sort out policy and process. This is all going to take awhile. Keegan (WMF) (talk) 23:24, 14 February 2019 (UTC)
We actually should seek the opinion of some people who are visually impaired. But I doubt we'll find many of those on Commons. - Alexis Jazz ping plz 20:41, 14 February 2019 (UTC)
There are a lot of similar text-based entities to parse here: On Commons alone we have file captions, timed text caption, file descriptions, file annotations, file names, and embedded metadata, and there are Wikidata captions for images, and finally alternative text for Wikipedia. With the exception of timed text, an image can have all of these elements: some may be redundant or conflict with others, some may be acceptably redundant, others may reinforce and complement each other. It will take wisdom and guidance to ensure that all elements are appropriately utilized on Commons, recognizing that usage anywhere else may involve entirely different captions, descriptions, alt-text, etc. --Animalparty (talk)
If it's worth doing, it's worth overdoing: User:Alexis Jazz/Fixed captions are bloody useless. - Alexis Jazz ping plz 05:35, 3 December 2019 (UTC)

Tools for easily adding captions to already uploaded files?[edit]

Is there any tool, currently or in development, similar to Cat-a-lot but for captions (Cap-a-lot?) to allow easy application of a single caption to multiple files? For instance, most of the files in this category would probably all have the same or very similar captions. It would handy to be able to select them all, add a blanket caption, then fine tune individual files as needed. And maybe a warning message if any have pre-existing captions so that overwriting is averted. --Animalparty (talk) 06:02, 14 February 2019 (UTC)

Relation between captions and annotations[edit]

This page touches on the similarities and difference between captions and file descriptions, it could also compare/contrast captions with Image annotations (and perhaps also incorporate some of the guidelines for informative vs non-informative captions). Some people have already used annotations as functionally equivalent to captions: casual browsing of Category:Images with annotations brings up frequent examples of files where the annotation is redundant, self-evident, and unhelpful, yet perhaps better expressed as a caption (e.g. 1, 2, 3). --Animalparty (talk) 19:55, 14 February 2019 (UTC)

caption: no caption, no cc-zero[edit]

File:Ohne_Titel_in_3D_1.jpg has a caption: no caption, no cc-zero, which is far away from any imaginable purpose and contradicts the general license for captions. What about this kind of captions? Who cares? --Herzi Pinki (talk) 05:47, 3 May 2019 (UTC)

It's a nonsense, so just revert it. --jdx Re: 05:51, 3 May 2019 (UTC)
User:Jdx and User:Herzi Pinki. I reverted them all. Around 5k... Amir (talk) 11:23, 31 July 2019 (UTC)

Styling section[edit]

Jean Fred and jdx, you both are translation admins: After the last update with dividing into file information and structured data the section Styling has to be almost completely to be deleted. From my side there are only two possible new short styles, i.e. they are not present until now. Alas, the page is in the Ext:Translation system now. Can I simply delete everything in the section and add the two styles? I get confused with these <!-- T:$number --> tags. — Speravir – 21:32, 17 May 2019 (UTC)

Go ahead and do delete the text that should go − in case the translation markup get messed up, no worries, I’ll fix it. I agree that translation markup can be confusing but it is a necessary evil :) Jean-Fred (talk) 22:00, 17 May 2019 (UTC)

Volunteer tester for Caption Bots[edit]

I've uploaded about 4.6k of my own photos to commons over the past 8 years, and am willing to volunteer them for test and validation. Michael D. Gunther (talk) 20:13, 14 June 2019 (UTC)

Adding Captions[edit]

Is it possible to add Captions to files in a way like you can add Descriptions and Properties to items in Wikidata. I am interested in a easy way for adding captions because there is the Reichsgesetzblatt in Wikisource and currently it is not eays to find a scan of a specific law. I have the connection from scan to law so I know what for a scan shows what for a law and I want to add captions for the files. Has somebody a bot script for adding captions or is there another tool for doing it. If yes please tell me in what for a format you need the information and then I can give this information to you. -- Hogü-456 (talk) 20:40, 12 August 2019 (UTC)


The part about search is not correct, actually it doesnt work. I think only way is to use CirrusSearch. Juandev (talk) 20:11, 21 August 2019 (UTC)

@Juandev: Can you clarify which part is not correct, and what does not work? Can you also expand on what you mean by “use CirrusSearch” − as far as I know, Special:Search is powered under the hood by mw:CirrusSearch.
Also, here is an example simple search, Special:Search/"Église Old Søgne", which does goes through the captions (at time of writing this, these French words are not in the wikitext description).
Jean-Fred (talk) 23:12, 2 December 2019 (UTC)