This page is presently inactive and retained primarily for historical interest.
If you want to revive discussion regarding the subject, you may try using the talk page (though your voice may not be heard) or start a discussion at the Village pump.
This page in a nutshell: Community input was requested on a good name for two new (additional) fields that will be added to Commons file pages: 'captions' and 'descriptions' (both to be named differently!). The Commons community has provided feedback, and the Structured Commons team is now taking the input into consideration.
The Structured Commons team is initially introducing two multilingual freeform text fields: 'captions' and 'descriptions'. Both need to be named differently. See below for more information about their functionality.
The 'caption' will be part of the initial Structured Commons feature release in Summer 2018 (see the development roadmap for reference). The release of structured multilingual 'descriptions' depends on how quickly other items can be completed.
Add your suggestions and preferences! (December 11, 2017 until January 3, 2018)
why can't we use label ? I don't see why that clashes so much with wikidata that is is unusable. It's very descriptive. (Adding more concepts is also very confusing, consistency has it's value, even if there might be small technical difficulties, please bother the developer with it by using a different keyname, but don't confront the user with that in your display names etc, unless you have to. —TheDJ (talk • contribs) 18:07, 11 December 2017 (UTC
Hi there. In this naming effort, we're trying to find terms that make the most sense. We've already gotten feedback that "label" and even "caption" were confusing just in terms of describing the functions to users, let alone developers. While it's true that for some of us, a term like "label" makes perfect sense, for many others (especially those not as familiar with Wikidata) it's just not working and we're trying to find a happy medium. RIsler (WMF) (talk)
In Getty Images, "Title" is used for the short text and "Description" is used for the longer descriptive text (although this is called "caption" in their API). Flickr uses "title" and "description". Unsplash has "title" for the short text (optional, and called "description" in the API) and "Story" for the longer text (optional). None of these platforms offer a structured, multilingual form of these fields. RIsler (WMF) (talk)
Hello. "Name" is indeed perhaps a bit too generic. "Summary" is an option, and one we've explored a bit, but we also use "Summary" as the header text for int:Filedesc. RIsler (WMF) (talk)
How about subtitle? (I’m thinking of the term’s usage in publishing, as opposed to that in film & video.) To me it suggests something longer and more descriptive than a filename (title) but still quite concise.—Odysseus1479 (talk) 02:46, 12 December 2017 (UTC)[reply]
"Summary" is good and I do not think it will clash with header int:Filedesc. Also possible "short description" (as opposed to "long description" which can be used for current "descriptions". --Jarekt (talk) 19:57, 12 December 2017 (UTC)[reply]
The example is curious because I would expect "Photo by Stöhr, from German Federal Archives, CC BY-SA 3.0." to be generated from structured data, not kept in a separate free-text field. "Label" is forbidden for good reason (clash with rdfs:label). "Subtitle" has two other meanings which can lead to confusion: Commons files include scans of books (which can have subtitles) and video clips (which are subtitled). "Annotation" suggests something that applies specifically to part of an image, not the whole image. "Notes" implies information that is very unspecific: it's often used in databases for information that doesn't fit into a structured field. "Name" implies something as short as possible; I wouldn't naturally call "Naming of the Rabindranath Tagore Street in Berlin, 6 May 1961." a "name". "Legend", "summary", "short description" all look good to me. Of these, I think "summary" has the most suitable connotations. "Caption" is such a useful word, even though it's ruled out as the name, that it should be in instructions, e.g. "Summary (this will be used as a caption in Wikipedia articles)". MartinPoulter (talk) 11:54, 14 December 2017 (UTC)[reply]
how about "designation"? I don't think it's the perfect word but it might be a good option. Note: I found this using a thesaurus and I suggest this seeing the meaning identifying word or words by which someone or something is called and classified or distinguished from others in the dictionary. - -Kaartic (talk) 16:13, 18 December 2017 (UTC)[reply]
"Alt" (similar to current alt option in [[File:...|alt=]] calling). Preferred to yet another semi-name search term, next to: filename, title, label, caption. Also, this new alt-label can be used by default as alt-text (in classical file calling). -DePiep (talk) 16:38, 18 December 2017 (UTC)[reply]
I don't think inventing new terms is the best way to reduce confusion. If it's going to be used as a caption, call it caption; if it's going to be used as a title, call it title. People will deal with the ambiguity easier than remembering yet another nondescript term. (Or maybe something like global caption / default caption / suggested caption.) AIUI the plan is to use it as both caption (ie. something to display under the image) and title (ie. something to display in lists like an image selection dropdown); I'd be skeptical of the assumption that the same string is always going to work well for both. --Tgr (talk) 17:30, 28 December 2017 (UTC)[reply]
A new (additional) metadata field on a Commons file page
Translatable
Similar goal as descriptions in Commons {{Information}} templates, but part of Wikibase (and therefore structured, inherently multilingual, part of solid APIs)
Can be much longer freeform text and may also support limited markup (such as italics, bold)
Will be indexed for searching Commons media files
Should NOT be named:
Description (to avoid confusion with descriptions in {{Information}} templates on Commons, and with Wikidata descriptions)
i'm missing context that led to this list of options... Do we even need a description ? Maybe it's superfluous ? My point being, I like metadata as much as the next guy, but this is not something I ever felt a need to use yet really and now soon i have a filename, a label, a 'description', a full description (information template like) and later possibly and alt text for the vision impaired ? So where am I using this, why am I investing effort as a curator to fill this, patrol it, who is the audience etc... —TheDJ (talk • contribs) 18:09, 11 December 2017 (UTC)[reply]
'description' It is now clear to me that this is going to be analogous to the description in the information template, and I thus think that from a user's perspective it should simply be "description'. There should be no confusion, as the function has the same purpose. Wherever we NEED to be more specific, we can just disambiguate by saying "structured data" vs "information template". —TheDJ (talk • contribs) 17:04, 13 December 2017 (UTC)[reply]
"data about this image" or "tags"--if I understand this correctly the information will work similarly to blog tags or categories. I would really like to somehow simplify the information spaces like TheDJ mentioned, but I understand that while things are changing we may just have lots of different metadata fields. Rachel Helps (BYU) (talk) 21:23, 11 December 2017 (UTC)[reply]
Actually, later on we'll add the Wikidata "depicts" property to entities in the Wikibase instance at Commons. Those will be closer to "tags". The descriptions being referred to here are long, freeform, multilingual text fields. Commons already has Description fields that can support text in multiple languages, but this is currently achieved in an inelegant way via the template system. We think we can improve on that. This proposed new implementation will utilize the new Wikibase instance on Commons to store these fields in a structured manner that is similar to how multi-language support works for Labels and Descriptions for Items in Wikidata. RIsler (WMF) (talk)
I don't understand what the "caption" will be used for. Captions on Wikipedia usually contain some of the information that's in the Commons description, and would usually be chosen according to the context of how an image is used. E.g., the caption on the image on this page is "Naming of the Rabindranath Tagore Street in Berlin, 6 May 1961.", which includes the event, and the date. That may be a good caption for an article on the Rabindranath Tagore Street. However, if you were using the image on a page to illustrate en:Walter_Ruben_(Indologist), you may instead use a caption such as "Walter Ruben (right) in 1961". This makes it impossible to choose a single short caption for an image, since you can make many different captions by taking subsets of the information in the description and other fields. --ghouston (talk) 04:21, 12 December 2017 (UTC)[reply]
The new, multilingual caption can also be used in the way you described, but it's much better suited for expanding the usefulness of Commons data in other software. For example: imagine a new tool that embeds Commons media on websites, with metadata automatically selected to match the language of the site (or the viewer's preferred language). With a structured caption that has entries in multiple languages, it is much easier to write those sorts of tools. This could also potentially help images show up better in image search engines (Google Images, Commons Crawl, etc). RIsler (WMF) (talk) 19:53, 12 December 2017 (UTC)[reply]
I see. I'd be wary of introducing such a duplication of data into Commons if it could be avoided. For all existing files, you won't have captions anyway, so you'll be deriving them from description or filename. Also I'm not sure that it would be good to expect people uploading files to Commons to need to enter the same thing twice as description and caption, and it may be hard to bot uploaders to set a caption. I'd suggest, at least initially, simply using the description, if it's fewer than n characters, or using the first n characters followed by "..." otherwise. That would still give the option to tweak the caption by adjusting the initial text in the description. --ghouston (talk) 22:30, 12 December 2017 (UTC)[reply]
If it's intended to replace the description field in {{Information}}, calling it description is going to be far less confusing than inventing a new name. (Once author, source, license and alt text are moved to a structured format, are we going to invent new terms for each of those too?) The clash with Wikibase descriptions is more problematic, but maybe just call it file description to avoid that? --Tgr (talk) 17:30, 28 December 2017 (UTC)[reply]
Response from the Structured Commons team (January 11, 2018)
Thanks to everyone who contributed their feedback. Comments are now closed, and we're considering all the input as we work on next steps.
To summarize the comments so far:
There's a wide range of feelings on how we should label the "caption"
For "description", there seems to be more common ground; a split between using "detail" or "details", or retaining some form of "description"
A few respondents expressed concern about potentially confusing users with new terminology
The Structured Commons team is now taking this input into consideration as we move to the next steps of determining what is feasible. As some respondents mentioned: if the new structured data entities can replace items of the same name that are currently stored in templates, there's less of a need to rename things. However, it's not yet clear that replacement is desired by the community or ideal from a data migration perspective.
The Structured Data Team will provide an update this quarter on next steps and recommendations.
My afterthoughts: Let's take a step back and think about our final goal. One of our most pressing needs to reach that goal is to attract talented/diverse contributors (reporters/field photographers/interviewers/people who tour film festivals/people who meet politicians all day/normal people/etc most of whom are less technical than the average Wikipedia editor). Our software should use the vocabulary THEY are used to, which is either "Title" (thanks RIsler for the research) or "Caption". A more generic term would make us less user-friendly, and thus lead many of them to Google Maps (ex-Panoramio) or Flickr or social networks, instead of Commons. So, just a wild idea: how about changing the term "title" in the API to something else like "id"? Yes that would be a huge change and take months to implement and break countless third-party applications (implementing the change only in the UI, or only in Wikibase, or using "caption", would greatly ease the task, though); but it is only a problem from us developers' point of view, and that's better than using non-straightforward terminology for the decades or centuries to come. Non-straightforward terminology leads to less users, and to lower quality of the metadata as new users misunderstand what is expected from them. Cheers! Syced (talk) 08:54, 15 February 2018 (UTC)[reply]
Comment See my thoughts and questions on the Talk page - PKM (talk) 20:33, 11 December 2017 (UTC)
Support detail. --Liuxinyu970226 (talk) 04:36, 15 December 2017 (UTC)