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

Commons:Village pump - Wikimedia Commons

Commons:Village pump

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

Shortcut: COM:VP

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

Welcome to the Village pump

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

Please note


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

Purposes which do not meet the scope of this page


Search archives


Start a new discussion


A village pump in Burkina Faso [add] Centralized discussion See also: Village pump/Proposals • Archive
Template: View • Discuss  • Edit • Watch

Contents

SpBot archives all sections tagged with {{Section resolved|1=~~~~}} after 1 day.

December 10[edit]

Multilingual file captions coming this week[edit]

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) (talk) 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) (talk) 20:13, 9 January 2019 (UTC)

Captions are live[edit]

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) (talk) 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 (talk) 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 (talk) 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) (talk) 19:44, 10 January 2019 (UTC)
Make this edit to your user css to disable the box. Thanks. Mike Peel (talk) 19:48, 10 January 2019 (UTC)
Thank you Mike, I was coming over here to copy your link :) Keegan (WMF) (talk) 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 (talk) 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 (talk) 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 (talk) 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 (talk) 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) (talk) 20:39, 10 January 2019 (UTC)
@Mike Peel: thanks, now individual opt-out works. --Te750iv (talk) 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 (talk) 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) (talk) 23:43, 10 January 2019 (UTC)
Tracked in Phabricator
Task T213571
@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) (talk) 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 (talk) 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? -- (talk) 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 (talk) 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 (talk) 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.— Preceding unsigned comment added by Speravir (talk • contribs) 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 (talk) 09:42, 14 January 2019 (UTC)

Good practice ?[edit]

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)
(Edit conflict) 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 (talk) 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) (talk) 18:55, 10 January 2019 (UTC)
@Huntster, Racconish: sorry, forgot to ping above. Keegan (WMF) (talk) 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) (talk) 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) (talk) 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 (talk) 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 (talk) 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 (talk) 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 (talk) 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 (talk) 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) (talk) 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 (talk) 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ů (talk) 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) (talk) 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 (talk) 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) (talk) 18:36, 11 January 2019 (UTC)

Proposal to remove captions feature[edit]

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. -- (talk) 19:29, 11 January 2019 (UTC)

  •  Support As proposer. -- (talk) 19:29, 11 January 2019 (UTC)
  •  Comment 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 (talk) 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)
  •  Support. 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 (talk) 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 (talk) 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 (talk) 20:46, 11 January 2019 (UTC)
  •  Oppose Another example of our proud tradition of immediately shitting on improvements to Mediawiki software. Maybe we try something different this time. Gamaliel (talk) 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. -- (talk) 20:32, 11 January 2019 (UTC)
  •  Oppose 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 (talk) 20:14, 11 January 2019 (UTC)
  •  Comment @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. -- (talk) 20:28, 11 January 2019 (UTC)
  •  Support per above. Sneeuwschaap (talk) 20:32, 11 January 2019 (UTC)
  •  Oppose 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 (talk) 20:41, 11 January 2019 (UTC)
  •  Oppose 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 (talk) 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 (talk) 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 (talk) 21:10, 11 January 2019 (UTC)
        • Again, one may hide the thing, but not get rid of it. Feel the difference. Incnis Mrsi (talk) 06:48, 12 January 2019 (UTC)
  •  Oppose A first and important step for Structured Commons. Let's try and help to improve it. Raymond 20:50, 11 January 2019 (UTC)
  •  Oppose per Gamaliel, Abzeronow and Raymond. Strakhov (talk) 20:55, 11 January 2019 (UTC)
  • Weak  Oppose, 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)
    • Captions for categories? Do they actually need captions? Incnis Mrsi (talk) 06:48, 12 January 2019 (UTC)
  •  Support --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 (talk) 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. -- (talk) 22:24, 11 January 2019 (UTC)
  •  Comment 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) (talk) 21:39, 11 January 2019 (UTC)
  •  Oppose 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 (talk) 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. -- (talk) 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) (talk) 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 (talk) 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)
  •  Oppose, 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 (talk) 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. -- (talk) 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 (talk) 22:49, 11 January 2019 (UTC)
  •  Oppose 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. -- (talk) 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 (talk) 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)
  •  Oppose Impossible to say better than Raymond and Multichill did. Christian Ferrer (talk) 22:48, 11 January 2019 (UTC)
  •  Comment @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 (talk) 23:11, 11 January 2019 (UTC)
  •  Comment 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 (talk) 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 (talk) 00:30, 12 January 2019 (UTC)
        • The number is also displayed in the page information [3], and does stay the same if the page is renamed. --ghouston (talk) 00:48, 12 January 2019 (UTC)
  •  Oppose 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 (talk) 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 (talk) 06:48, 12 January 2019 (UTC)
  •  Oppose, 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 (talk) 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 (talk) 06:48, 12 January 2019 (UTC)
  • Weak  Oppose 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 (talk) 03:06, 12 January 2019 (UTC)
  •  Oppose I like it. --Jarekt (talk) 03:45, 12 January 2019 (UTC)
  • Weak  Support -- 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 (talk) 04:14, 12 January 2019 (UTC)
  •  Oppose 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 (talk) 09:42, 12 January 2019 (UTC)
  •  Oppose 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)
  •  Oppose 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 (talk) 16:10, 12 January 2019 (UTC)
  •  Oppose the feature is an important step towards Structured Data. Surely one can opt out by writing a common.js file. Rama (talk) 16:15, 12 January 2019 (UTC)
  •  Comment 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 (talk) 21:08, 12 January 2019 (UTC)
  •  Oppose 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)
  •  Support 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 (talk) 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 (talk) 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)
  •  Comment 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 (talk) 13:09, 13 January 2019 (UTC)
  •  Oppose 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 (talk) 13:09, 13 January 2019 (UTC)
  •  Oppose 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 (talk) 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)
  •  Oppose --ChristianSW (talk) 17:01, 13 January 2019 (UTC)
  •  Support -- 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 (talk)
  •  Support, per nom and all preceding discussions. -- Tuválkin 11:55, 14 January 2019 (UTC)
  •  Oppose 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)
  •  Support 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ů (talk) 22:36, 17 January 2019 (UTC)

disable captions on redirects[edit]

Tracked in Phabricator
Task T213594

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 (talk) 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) (talk) 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 (talk) 02:13, 12 January 2019 (UTC)
Of course. I think there already phabricator ticket for it. --Jarekt (talk) 03:47, 12 January 2019 (UTC)

poor descriptions of files (Proposal for improvement)[edit]

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 (talk) 01:39, 12 January 2019 (UTC)

Lessons learned?[edit]

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 -- (talk) 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 (talk) 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 (talk) 05:37, 16 January 2019 (UTC)
FULL ACK @:. --Herzi Pinki (talk) 01:27, 15 January 2019 (UTC)
At least it is clear from this poll that the majority of volunteers think differently ;-) Braveheart (talk) 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 (talk) 22:43, 17 January 2019 (UTC)

Adult content?[edit]

Hi. I found this via Google search. I guess it could be a painting by this painter (it is even published with a compatible license, CC BY-SA 2.0) but Flickr delivers me an "adult content" lock and does not let me check the image. Could someone with a Flickr account (I do not have one) check if the image would be OK here? Strakhov (talk) 12:27, 8 January 2019 (UTC)

  • It shows a male adult bagpiper and a drummer boy, both closed clothed and standing, not touching each other, faces practically expressionless. They stand in an unremarkable countryside path or mountain trail. Nothing “adults-only” here. Seems to have been flagged by mistake or malice, and Flickr, of course, swalled it — hook, line and sinker, as they do. -- Tuválkin 15:01, 8 January 2019 (UTC)
  • I marked it for (human?) review, lets see how long it takes. -- Tuválkin 15:03, 8 January 2019 (UTC)
    • @Tuvalkin: "closed" => "clothed", or did you mean something else? - Jmabel ! talk 17:19, 8 January 2019 (UTC)
      Ouch, omg, yes. -- Tuválkin 17:34, 8 January 2019 (UTC)
    • There's also the possibility that the Flickr uploader set their default safety level to moderate and didn't change it for this image. There are other innocuous images in their photostream also marked moderate: [4], [5], [6]. clpo13(talk) 19:41, 8 January 2019 (UTC)
      I have a Flickr account. I am not allowed to see their photostream, [www.flickr.com] shows as "Certo Xornal hasn't made any photos public yet." I don't mind seeing "Adult" content. How may I see their photostream?   — Jeff G. please ping or talk to me 00:22, 9 January 2019 (UTC)
@Jeff G.: in your preferences under Privacy and Permissions, you need to set SafeSearch to Moderate or Off: [7]. clpo13(talk) 00:40, 9 January 2019 (UTC)
@Clpo13: On your linked page, I have checked all three boxes. On the parent page [www.flickr.com], under "Content filters" and next to "Search settings", I have "Content type: All".   — Jeff G. please ping or talk to me 00:58, 9 January 2019 (UTC)
Wow, hubba hubba, va-va-vavoom! :) --Animalparty (talk) 00:10, 9 January 2019 (UTC)
The bagpiper appears to have the lowermost four buttons of his knee-breeches unbuttoned at his left knee, if that excites you. The drummer also has one of his six coat buttons unbuttoned... AnonMoos (talk) 14:49, 14 January 2019 (UTC)
Thank you everyone. Apparently Flickr2commons knows how to crack the Flickr protection. So here it is. It's signed by "A. Jaspe" and it's dated in 1876 or 1896. I guess ...1876, since the painter died in 1887. Strakhov (talk) 13:20, 9 January 2019 (UTC)
  • Adult content -> Paying bills, mowing the lawn, planning for retirement, driving the speed limit ... for heaven's sake save the children! GMGtalk 13:44, 9 January 2019 (UTC)

Nudity and [lack of?] educational focus[edit]

See also: Commons:Village pump/Proposals#Exhibitionist uploads.

I know "Commons is not censored", and I personally have over 1000 photos here of nude or nearly nude people among my 50,000+ uploads (mostly body-painted participants in Seattle's Fremont Solstice Parade), but I really don't like seeing them categorized in ways that seem to have more pornographic than educational intent. E.g. is there really any appropriate reason to single out Category:Nude women with curls‎, Category:Nude women with red hair‎, etc.? I note that there are no analogous categories for men. - Jmabel ! talk 05:09, 9 January 2019 (UTC)

Welcome to the free repository that anyone can edit ;). I'm not fond of hyper-splitting either, but some nude women sub-sub-sub-categories have arguable artistic value (Category:Paintings of nude women standing outdoors and Category:Nude or partially nude women in the morning are at least based in classical aesthetics). Categories like Nude or partially nude women in or next to inflatable pools probably won't be a place for art historians to look, but it as well as Nude women with red hair might plausibly help someone find what they're looking for, be they artists seeking reference photos or someone wanting to illustrate an article on oil wrestling. Of course, there is some actual graphic material and depictions of sexual acts that many would probably consider pornographic (e.g. Category:Sex practices and NSFW categories therein), but low quality, unrealistically educational images can always be nominated for deletion. --Animalparty (talk) 05:42, 9 January 2019 (UTC)
@Jmabel: Some people are visually oriented and look for particular types of images, and some of those people like to categorize that way.   — Jeff G. please ping or talk to me 05:48, 9 January 2019 (UTC)
And that explains the lack of similar categorization of men how? - Jmabel ! talk 06:25, 9 January 2019 (UTC)
Also note that while there is a "Penis Fighter Barnstar" there is no "Vulva Fighter Barnstar" or "Vagina Fighter Barnstar".
@Jmabel: I think that nudes of blokes are more quickly deleted than those of female humans, also note that while there is a "Penis Fighter Barnstar" there is no "Vulva Fighter Barnstar" or "Vagina Fighter Barnstar". (see the image above (on mobile)/to the right (on desktop)) I don't think that nude photographs are automatically out of scope, but images usually get more detailed categorisation when there are more images to categorise, and "the Anti-Penis Police 👮‍♀️" usually nominate every nude male photograph for deletion they see. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 12:26, 9 January 2019 (UTC)
Donald Trung -- the "penis fighter" thing was because there was a constant flow of low-quality cell-phone-camera images taken by drunk guys of their own genitals which were being uploaded here. Frankly, we only need a certain number of blurry drunk penis selfies, and any more beyond that would be "surplus to requirements". Whatever problems there are with revealing female images being uploaded, they do not take that particular form or tend to cause that particular problem (though there is an image File:Nobreasts.svg)... AnonMoos (talk) 15:15, 14 January 2019 (UTC)
Welcome to the heteronormative patriarchy of the free repository that anyone can edit.
It is not possible to start a sensible discussion about existing systemic bias on any Wikimedia project without quickly being derided and painted as a fringe loon. However this project relies on contributions from people living in the real world, and any real world bias will naturally be reflected here. Scientific and statistical facts exist, regardless of rhetoric or who points them out.
Good luck should you want to try to fix it. -- (talk) 12:43, 9 January 2019 (UTC)
For what it's worth, I believe I've uploaded a roughly equal number of such images of men and of women. Never bothered counting. @Donald Trung: I don't think there is any doubt that the images are in scope. My issue is how they are now being categorized by a third party: that the photos of women are being described with what I consider very objectifying criteria.
Examples of the photos I'm talking about can be seen in Category:Solstice Cyclists and its child categories. Possibly NSFW. - Jmabel ! talk 18:32, 9 January 2019 (UTC)
If pictures are inadequately described, for example insufficient in objective categories or insufficient in non-objective ones, that can be remedied by supplying what is missing. I do more buildings and structures than people, and when it's people, they are mostly clothed and my attention goes not to objective criteria but to other things like birth and death dates, occupation, home town, and education. Often I think details which are already easily visible in pictures of naked women are categorized with a painstaking care that is frivolously applied. That attention would more profitably be applied to other subjects and other criteria. That is not because frivolous, objective detail is evil, rather it is because similarly precise attention to other subjects would evince information not otherwise as easily seen. Jim.henderson (talk) 21:01, 9 January 2019 (UTC)
Entirely agreed.
But the problem here isn't lack of categories. It's that categories are being added to pictures of women that treat women as objects. I don't think this is in accord with policy. And I find it particularly objectionable when it is being done to photos I've taken. When I photograph someone and upload here, I don't like finding myself implicated in the objectification of that person. I realize that I'm providing a license that lets someone go elsewhere and do pretty much whatever with the photo as long as they don't violate the person's personality rights, but still, I think the tone of descriptions/categories on Commons is worth arguing. And, also, I think this sort of objectification at least borders on a personality rights issue. - Jmabel ! talk 00:12, 10 January 2019 (UTC)
I think the lack of male nude subcategorization is mostly due to the fact that not a lot of people take (find beauty and value in) photos of nude men, for example we don't even have a featured picture of nude men, subcategories follow content. --Trougnouf (talk) 01:42, 10 January 2019 (UTC)
Imagine people on Mars studying the pictures flying through the Internet, to learn what Earthlings look like under our clothes. Typically we are female adults, young, white and pretty, with big round titties. Everyone else is odd. Jim.henderson (talk) 19:30, 10 January 2019 (UTC)
Yes, this is largely cultural too, the female body is both more celebrated and appreciated than the male form, these women tend to be "adults, young, white and pretty" because nudity is more acceptable in Western cultures than in let’s say Eastern cultures, in places like Japan, Pakistan, and the Philippines there aren't that many exhibitionists and nudity is frowned upon there, as nudity is more acceptable in Europe, North America, South America, and Oceania these women tend to be White because Asians only make up a minority there. Because older women aren't as revered for their beauty (which subconsciously has to do with their fertility) Deletionists will be quick to nominate them. Also people tend to say that nudity and sexual related images should only be of well-known porn stars who also tend to fall into those demographics more (I'm not saying that there are no 90 year olds in the porn industry, I’m just saying that those usually fail the w:en:WP:NOTABILITY standards). And again Wikimedia Commons has developed an ingrained form of penisphobia and selfiephobia, combine these two (2) with the cultural norms that disapproves of anything but the young white woman’s physiqué and it becomes clear why men are severely underrepresented. Just peruse nudity-related deletion requests and one will find that the vast majority of them are of males.[dubious][citation needed] (anecdotally speaking, of course.) And the reason why they’re all mostly adult is a bit too obvious as it's something everyone here agrees on.
Now here is something I want people to think about, look for images of any “tribal traditional clothes” or “ethnic clothes” of any group in the world and most images seem to be of females, most people who visit my native Vietnam often go visit the Hmong (Mieu) people and many tourist agencies both inside and outside of Vietnam showcase these people by showing either young girls, adult women, or even elderly women, for the life of me I can’t remember a single poster showing a Hmong man in his traditional clothing, now the male traditional clothing (to me) looks more interesting as many Hmong men wear a Chinese changshan suit with a French barrett, these clothes perfectly illustrate both Chinese and French influence as the Hmong from a place I worked for had a Chinese King and they were colonised by the French. Yet any image of basically any minority or even the dominant Kinh (Metropolitan/”City-people”) ethnic group is almost always represented by the females, just search for “Ao Dai” to see (and yeah, I wear one of those every February and during formal occasions but outside of Vietnam I’ve never seen the Vietnamese people be represented by a male ao dai). Exception: Balkan(ese?), Greek, and Sikh people do seem to have their male national dresses represented by tourist agencies and magazines, but they are literally the only ones that come to mind.
Which brings me to the overrepresentation of the female form, as there is already a bias favouring the clothed woman, why wouldn't there be a bias favouring nude women? As both men and women like looking at naked women, and even look at the same body parts. This is a bias that we at Wikimedia Commons can't solve if we keep nominated good quality and potentially educational male nudes because it's one editor’s opinion that “Commons doesn't need any more penises”. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 00:36, 11 January 2019 (UTC)

All well & good, but little to do with what I initially asked about.

  1. For what it's worth, as I said above, I believe I've uploaded a roughly equal number of such images of men and of women. Never bothered counting, so if the thing about what does & doesn't get uploaded is directed at me, it missed the mark.
  2. My issue isn't the presence or absence of various content. It is the addition of objectifying categories to pictures of women. Yes, I suppose we could add objectifying categories to pictures of men, and at least address the balance, but I think that is the wrong way to go. Am I the only person here who thinks these categories do not sit well with Commons educational scope?

Jmabel ! talk 01:05, 11 January 2019 (UTC)

You are probably the only person that cares about a completely non existent issue (Non existent in the real world outside of your head). There simply is no such thing as "objectifying categories" it is complete nonsense. Extremist political and social justice agendas should have no place on commons. Oxyman (talk) 01:26, 11 January 2019 (UTC)
Just because you don't understand doesn't mean it is complete nonsense, and just because you don't like it doesn't mean it's extremist. It seems a quite mainstream issue.--Prosfilaes (talk) 01:38, 11 January 2019 (UTC)
Well obviously I do not stand under it, but I do totally comprehend what this is about. Strange that you claim to know what I "understand", I would say that it is arrogant to claim to know that. Just because you seem to think erroneously that it is a mainstream issue does not make it so. I think it is extremist to claim that commons categories are a mainstream issue. That is quite absurd. You make no point other then you disagree with me but you seem to object to me stating my disagreement. That seems to be the actions of an extremist does it not? Oxyman (talk) 01:49, 11 January 2019 (UTC)
  • @Oxyman: you just said that «social justice agendas should have no place on commons». (Let’s that sink for just a bit.) This is a free media repository — its very basic idea is about social justice: inclusive, diverse, empowering, intersectional. Now, why don’t you let go of the dog whistles and speak clearly about what’s bugging you? -- Tuválkin 04:15, 11 January 2019 (UTC)
Please don't misquote me or take what I said out of context, I actually said "Extremist political and social justice agendas should have no place on commons." I thereby equated this type of social justice agenda to extremist politics which is what this is actually about. You'll have to educate me as to what exactly "let go of the dog whistles" means as I have no idea. I think commons should be allowed to go about it's mission of providing a free media repository without pressure or lobbying from extremist political interests which will inevitably end up in some form of censorship. This means that people creating legitimate categories should be able to go about their business with people assuming good faith. This entire imagined issue only exists in the minds of people assuming bad faith. Oxyman (talk) 12:18, 11 January 2019 (UTC)
  • @Jmabel: (answer to the 19.01.11+01:05 post above): You’re not the only person troubled by the matter. I am however at odds about what to do. In my views of Commons, categorization is paramount — as I see it as the tool of choice for most uses, including search and selection by reusers, who are through cats shown multiple choices for the same file usage need. I have no qualms about throughly categorizing all aspects of, say, this photo, for a reuser might be looking for one or several of those specific traits. I understand that there is a difference between categorizing something as "Trams on steep grades" or as "Kneeling redhead women looking at the viewer", and maybe that’s why my work in Commons is more often about the former than about the latter. However:
  • detailed categorization of a human subject should not be problematic in and by itself, any more detailed categorization of anything else is (and of course I’m excluding here inappropriate cats a troll might create and or redlink to a photo);
  • perverts might make use of detailed categorization for sure (although I find unlikely it’s a widespread situation, given the amount of material online specifically targeted, easier to find and browse than Wikimedia Commons), but then again if we shy from catering for those who seek avidly always and only for, say, "Smiling topless women with crowfeet (freckles apparent), supine, sunglasses on forehead", we will be unavoidably catering for those who are not any less unsavory but who settle for "Nude women" and anything goes (we could avoid the categarization of nudity wholesale, but that raises a host of other issues, probably worse, and that was explicitly not your point);
  • and the existence of said “perverts”, or the very prevalence of “perversity” in general, is a problem of the whole society, worldwide — it unavoidably affects Wikimedia Commons as it does affect anything else, but it`s a problem that cannot be solved, or even effectively faced, with specific narrow measures we could take concerning something as derivative and contingent as media file page categorization.
  • As for being educational, I some times feel that being focusedly educational and avoiding the possible sensual content of a photo, vis-a-vis the model’s wishes or expectations might backfire: If what was uploaded as a sexy self portrait is being categorized for its erotic content, it would be less unexpected and, even, less disstressing than to find out that said photo is now illustraring an Wikipedia article or an Wikitionary entry on, say, "Ptosis (breasts)" or "Elbow rash" (way to be both educational and, frankly, a dick).
That’s what I can say to address your concerns (which are partly also mine) unsatitsfactory as it is. -- Tuválkin 04:15, 11 January 2019 (UTC)
  • I'd say that the male categories should mirror the female ones, once enough files are in a category people start creating more specific subcategories to more easily find what they're looking for, a reason as to why more specific "objectifying" (note that these photographs are digital objects) categories are created. Maybe this difference exist because photographs of female humans get used more often even if the numbers were roughly equal. Category trees reflect usage, don't forget that we can have one hard to navigate category with a thousand images or a category tree that caters more to re-users. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 12:37, 11 January 2019 (UTC)
Perhaps one might define "object". Are there pictures that depict no objects? Can such a picture be objectified without editing the picture? Jim.henderson (talk) 03:51, 12 January 2019 (UTC)
I am using "object"/"objectify" in the sense of treating a human as an "object" rather than a "subject": focusing on physical characteristics that have nothing to do with their humanity. - Jmabel ! talk 05:29, 12 January 2019 (UTC)
It is an overused to the point of being meaningless phrase. Perhaps you can explain how "objectifying categories" can be guilty of a thoughtcrime Oxyman (talk) 14:30, 12 January 2019 (UTC)
"guilty of a thoughtcrime" are your words, and not something I am saying at all. People can think what they want. They can think, for example, that all women are bimbos, that all men are scum, that Donald Trump is either a savior or a demon, but they don't get to add Commons categories accordingly.
That is, of course, not an exact analogy, but I don't have a bunch of time right now, headed out the door. - Jmabel ! talk 17:12, 12 January 2019 (UTC)
Well if a category is subjective discuss it and get it removed on those grounds, but you have not pointed to any subjective category. You seem to have a problem with objective categories as you assume bad faith of the creators. If we remove that assumption and look only at the objective category we are left with no problem. Your entire argument is constructed by assuming bad faith with is entirely analogous with the thoughtcrime concept. You seem to have enough time to post your extremist agenda ad nauseam so it appears you are time selective here. Oxyman (talk) 17:31, 12 January 2019 (UTC)
Friends in Ohio
Nobody's naked here, but still maybe a few hypotheticals can help. Thus far, this photo is categorized by our names and location. They are not categorized by height, age, color, clothing or sex, which are obvious differences, thus perhaps are objective qualities, hence using them to categorized the picture would be bad. But, those qualities do have something to do with our humanity, so perhaps categorizing according to those qualities would be good. I also think my friend is wise, honest, kind, and pretty, which strike me as subjective judgments, much influenced by my respectful admiration for her. Does that also make them good as categories? — Preceding unsigned comment added by Jim.henderson (talk • contribs) 23:13, 12 January 2019 (UTC)
IMHO the decribed problem has very much to do with the facts, that while Wikipedia is the encyclopedia that everone can edit, Wikipedia is also the Encyclopedia that nearly no one does edit. With more editors many things would be better. If I make fotographs at events and get asked about what I am doing, I try to motivate the person to contribute to Wikipedia (with media or text) her- or himself. I specifically remember of a talk with one of the organizers of a Dyke March about Wikipedia while taking photos. Dyke Marches are all about making one group of society more visible to the public and participants in such an event are activists, that put time and energy in activism: people you would be expecting to be more likely than others to contribute to this project. But even when asked to contribute, nothing happens. --C.Suthorn (talk) 15:42, 13 January 2019 (UTC)
I guess it's partly my fault that we are wandering afield. Anyway a couple months ago I explained to a street recruiter for Greenpeace, that I'm already a fully committed Wikipedian, leaving no public passion for other activities. I have flirted with other crazy cults that pulled me in less completely, and I guess other potential fanatics have found their niche, too. But, yesterday at Wikipedia Day in NYC I was one of the old-timers speaking to a dozen recruits, directing them to a news report and perhaps we snared a few. Jim.henderson (talk) 15:37, 14 January 2019 (UTC)

For some past discussions of overspecific microcategorizations of images of unclad or scantily-clad women, see Commons:Administrators' noticeboard/User problems/Archive 55#Strange categories created by Neelix... -- AnonMoos (talk) 15:15, 14 January 2019 (UTC)

January 10[edit]

PSA: Disable Captions Box[edit]

For anyone who doesn't want to see the captions box, add the text

.filepage-mediainfo-entitytermsview { display:none;}

to Special:MyPage/common.css -FASTILY 06:33, 11 January 2019 (UTC)

@Fastily: You probably want to include .mw-slot-header {display:none;} in that too to hide the header. Thanks. Mike Peel (talk) 07:25, 11 January 2019 (UTC)
Mike, for me the line Fastily presented is enough. can you give an example where “your” rule is needed? — Speravir – 00:04, 12 January 2019 (UTC)
@Speravir: If you have caption disabled but have that section header alive, when you browse the file with existing caption, you will see "Structured Data" H1 (= Header = ) header and then H2 Summary == {{int:filedesc}} == section. That is a mess. — regards, Revi 11:21, 13 January 2019 (UTC)
Thanks, Revi, but I still do not get and so I am still interested in an example. (Though I will actually use the new collapse gadget, see below.) — Speravir – 01:30, 14 January 2019 (UTC)
Never mind, I noticed it meanwhile myself. — Speravir – 23:02, 14 January 2019 (UTC)
Thanks. It would be nice to be able to hide and show it back with one click. Regards, Yann (talk) 07:28, 11 January 2019 (UTC)
I've filed a Phabricator task to look into adding some CSS ID anchors so that this can happen. Keegan (WMF) (talk) 17:46, 11 January 2019 (UTC)
@Keegan (WMF): Given Commons users' diversity, it would behoove every good developer to ask "what if" questions, like "What if some of the target audience doesn't want this change?" and plan a good answer. Every addition to the UI should have a corresponding CSS ID anchor by design.   — Jeff G. please ping or talk to me 17:56, 11 January 2019 (UTC)
While I understand the need for structured data. Do the caption fields have to be this massive? And is there a way to hand pick the language's? Natuur12 (talk) 21:46, 11 January 2019 (UTC)
In the moment only by adjusting your Babel box, Natuur12. So, you should see fields for Dutch, English and German, now. — Speravir – 01:30, 14 January 2019 (UTC)
Thanks Speravir goodbye part off my babel-boxes it is then. Natuur12 (talk) 12:21, 14 January 2019 (UTC)
Added to Commons:File_captions#How_can_I_mask_the_captions?. Jean-Fred (talk) 12:21, 11 January 2019 (UTC)

Another option: this addition to Special:MyPage/common.js will collapse the box and show an "Expand" button to display it again. There's probably a way to gadgetise that, if anyone knows how to do that. Thanks. Mike Peel (talk) 22:02, 11 January 2019 (UTC)

Didym, Zhuyifei1999 (and Perhelion, alas fairly active) are the ones I know. — Speravir – 00:04, 12 January 2019 (UTC)
 Done &  Done MediaWiki:Gadget-Collapse-Captions.js & MediaWiki:Gadget-Hide-Captions.css. Jean-Fred (talk) 20:44, 12 January 2019 (UTC)

What I read here is if you do not want your Commons image pages filled with pointless empty boxes, either hack your css to make them all invisible, and forget about the noobs, or delete your babel boxes.

Huh, how is anything which causes this level of damage and disruption possibly a good thing? If an unpaid volunteer disrupted the entire project to this extent, and refused to remove it or fix it within a couple of hours, we would be discussing how long to keep their account blocked, not pussyfooting about trying to write phabricator tickets that look like technical points that might be parked until convenient for someone to think about reading. -- (talk) 12:36, 14 January 2019 (UTC)

You don’t have to hack your JS/CSS, you can enable a gadget (a box to tick). Gadgets can be made "enabled by default" to be enabled for all users (including the ones you describe as « the noobs ».)
I imagine what I describe is not necessarily ideal in your view ; but things *are* simpler than « hack your CSS » :-)
Jean-Fred (talk) 20:39, 14 January 2019 (UTC)

Styling with CSS[edit]

Info: Section later added, hence the indentation. My first reply was a reaction to Jean-Fred’s message that he had created the gadgets. — Speravir – 23:02, 14 January 2019 (UTC)

Nice, Jean-Fred. Could you check whether you can add these CSS rules to the collapse gadget (mw.util.addCSS())? They work fine for me, but I had to use !important. I do not know whether this could be omitted when inserted with JS:
.filepage-mediainfo-entitytermsview.mw-collapsed .mw-collapsible-content { display: initial !important; }
.filepage-mediainfo-entitytermsview.mw-collapsed .mw-collapsible-content *:not(h3) { display: none;}
.filepage-mediainfo-entitytermsview.mw-collapsed h3 {
	display: block;
	border-bottom: 0;
	margin-bottom: 0;
	padding-top: 0;
}
(Edit: Only one !important necessary. — Speravir – 04:25, 14 January 2019 (UTC))
This makes the caption line (in English “Captions” ) visible. Or should we better add this only to Commons:File captions? — Speravir – 01:30, 14 January 2019 (UTC)
@Speravir, Jean-Frédéric: This way, it doesn't take up any space. - Alexis Jazz ping plz 03:08, 14 January 2019 (UTC)
Nice one, Alexis, works also together with “my” rules. But the line with border-bottomis redundant because it is already catched by the first line with border. In CSS this would be:
.filepage-mediainfo-entitytermsview {
	border: none;
	margin-top: -3em;
	text-align: center;
}
Wasn’t there a way to completely deactivate the MediaViewer, so your change would interfere with the file size info? — Speravir – 04:03, 14 January 2019 (UTC)
@Speravir: Don't know about that, but the border-bottom is not redundant. The border line removes the border around the whole feature. The border-bottom line removes the line under "Captions". There was a minor issue though, when a file has a caption a header with "Structured data" appears. The line from this header would cross the word "Captions". There are various ways to fix that (like changing -3em to -3.5em), but I've just disabled the header. - Alexis Jazz ping plz 06:19, 14 January 2019 (UTC)
Well, my reply was for this version, and written this way it was redundant. You are right that this is not the case for later versions. — Speravir – 23:02, 14 January 2019 (UTC)
@Speravir: I improved it some more. But I can't figure out how to reduce that massive 0.8em padding to 0.2em, which is more than enough and looks much better. - Alexis Jazz ping plz 07:37, 14 January 2019 (UTC)
@Alexis Jazz, Speravir: No problem, happy to help. No need for mw.util.addCSS() I think − gadgets can load both JS and CSS. I’m a bit confused now though on what I should add to which gadget − if you could clarify that for me ^_^'. Jean-Fred (talk) 08:23, 14 January 2019 (UTC)
@Jean-Frédéric: I'm a noob, if a gadget can load CSS that would seem like a better solution. Perhaps the padding can be reduced that way as well.. - Alexis Jazz ping plz 08:30, 14 January 2019 (UTC)
@Alexis Jazz: The top-padding of 0.8em is for the h3 header (but .filepage-mediainfo-entitytermsview has itself one). After I found jQuery css() Method I can tell you that you should change these 3 lines
$( ".filepage-mediainfo-entitytermsview h3" ).css( "border-bottom", "none");
$( ".filepage-mediainfo-entitytermsview h3" ).css( "margin-top", "2em");
$( ".filepage-mediainfo-entitytermsview h3" ).css( "margin-bottom", "-0.5em");
to something like this
$( ".filepage-mediainfo-entitytermsview h3" ).css({
	"border-bottom": "none",
	"margin-top": "2em",
	"margin-bottom": "-0.5em",
	"padding-top": "0.2em"
});
It didn’t work, so again ping @Alexis Jazz. — Speravir – 23:07, 14 January 2019 (UTC)— Speravir – 23:07, 14 January 2019 (UTC)
@Jean-Frédéric: Could you check whether this works? Add this one to the collapse gadget (jQuery prepend() Method):
$( ".filepage-mediainfo-entitytermsview.mw-collapsed" ).prepend("{{int:wikibasemediainfo-entitytermsforlanguagelistview-caption}}");
In worst case you must revert this. Then, I guess, we have to add the rules from above according to the style I presented to Alex, but I am not sure about this, too. — Speravir – 23:02, 14 January 2019 (UTC)
@Speravir: thanks, that helped, I think I have something now.
Default captions versus compact captions
@Jean-Frédéric: can you create a new gadget with the contents from User:Alexis Jazz/common.css and call it "Compact Captions"? It may need some more tweaking, but it works for me. It's compatible with the Collapse Captions gadget. I think Natuur12, Jcb (may still be big with 7 languages, but a lot smaller anyway), MPF and Trougnouf may like it. (you guys all complained about the size of the feature) - Alexis Jazz ping plz 08:39, 15 January 2019 (UTC)
@Alexis Jazz:  Done MediaWiki:Gadget-Compact-Captions.css. Jean-Fred (talk) 11:55, 15 January 2019 (UTC)
Just for your information: I added a Styling section in Commons:File captions and also rules I use now. Especially useful could be the part to show the caption in collapsed mode. — Speravir – 23:17, 15 January 2019 (UTC)
@Jean-Frédéric: Please add the following to the end of MediaWiki:Gadget-Collapse-Captions.js and check afterwards:
$( ".filepage-mediainfo-entitytermsview.mw-collapsed .mw-collapsible-content" ).css( "display", "initial" );
$( ".filepage-mediainfo-entitytermsview.mw-collapsed .mw-collapsible-content *:not(h3)" ).css( "display", "none" );
$( ".filepage-mediainfo-entitytermsview.mw-collapsed h3" ).css({
  "display": "block",
  "border-bottom": "none",
  "margin-bottom": "0",
  "padding-top": "0"
});
If after this edit the caption Captions still is not visible, then add in the first line an !important after initial, but inside of the quotes (!), cf. the according CSS rule above. If this does not work either, then revert. If it works I will reduce the styling text in COM:Filecaptions. — Speravir – 22:23, 16 January 2019 (UTC)

Getty Museum subcategories[edit]

Hi, I am trying to add categories for all files in Category:Media contributed by the J. Paul Getty Museum, and in particular Category:Google Art Project works in The J. Paul Getty Museum, by types of works: paintings, photographs, illuminated manuscripts, sculptures, etc. What other subcategories do you suggest? Drawings? Regards, Yann (talk) 06:43, 11 January 2019 (UTC)

Source categories are hidden and usually not subcategorized. Category tree is currently a bit of a mess. Categories like Category:Paintings in The J. Paul Getty Museum and Category:Photographs in The J. Paul Getty Museum tell something about what it is, not about who contributed it. Multichill (talk) 22:45, 11 January 2019 (UTC)
i do not find subcategory by type of work useful, other than 2D versus 3D. subcategory by decade of creation is more useful. wikidata does it better. Slowking4 § Sander.v.Ginkel's revenge 03:25, 12 January 2019 (UTC)
Then how to find all photographs or all paintings from the Getty Museum available on Commons? There is no other way than to have category for that. Regards, Yann (talk) 10:10, 12 January 2019 (UTC)
[www.wikidata.org] -- Slowking4 § Sander.v.Ginkel's revenge 13:21, 12 January 2019 (UTC)
@Slowking4: This is only available for works which have a Wikidata item, only a tiny part of the whole. Regards, Yann (talk) 12:26, 13 January 2019 (UTC)
for LOD GLAMs, they have uploaded all their object id's [www.wikidata.org] ; you have a better case for smaller institutions such as the Louvre, where we have some cleanup to do, i.e. File:Desiderio da settignano, san giovanni battista goupil, louvre, 1455 circa 02.JPG ; you can stay in your category cul-de-sac, i have moved on. -- Slowking4 § Sander.v.Ginkel's revenge 17:02, 13 January 2019 (UTC)
The full name is J. Paul Getty Museum, why don't we use it for categories? So I would redirect all categories under Category:Getty Museum. Then there is confusion between Category:Getty Center‎ and Category:Getty Museum. How do we fix that? Regards, Yann (talk) 10:23, 12 January 2019 (UTC)
@Multichill: I agree that categories need to be merged. What do you think? Regards, Yann (talk) 18:58, 12 January 2019 (UTC)
What are you confused about Yann? J. Paul Getty Museum is the organization and they have two locations:
This is also how everything is categorized (at least was before). So what do you want to change and merge exactly?
Renaming Category:Getty Museum to Category:J. Paul Getty Museum seems to be the more correct name. Creating Category:Collections of the J. Paul Getty Museum as an intermediate step for navigation wouldn't hurt either. What else?
Important remark related to what you said here: On Commons we generally don't mix the topic (what's in the picture) and the source (where did it came from). So take for example the MET donation I also worked on. We track the source in Category:Images from Metropolitan Museum of Art (hidden category) and we categorize by topic. Multichill (talk) 13:33, 13 January 2019 (UTC)
@Multichill: This rename proposal is OK for me. In Category:Collections of the Getty Center‎, we do have subcategories for types of works. That is exactly what I'd like to do. I didn't find them, as I looked for subcategories in the Museum main category.
Yes, the Museum includes 2 physical places. It seems better to have subcategories under the legal entity rather than the physical location. Regards, Yann (talk) 16:36, 13 January 2019 (UTC)

Tree layout proposal

J. Paul Getty Museum
-> Paintings
-> Drawings
-> Photographs
-> Sculptures
-> Sculptures in the Getty Center
-> Sculptures in the Getty Villa
etc. Yann (talk) 16:46, 13 January 2019 (UTC)

Gallica[edit]

I'm really sorry about this, but... I remember it's really easy to get the high-resolution Gallica images... but I forget how. Please remind me. Adam Cuerden (talk) 13:56, 12 January 2019 (UTC)

Commons:Gallica? --GRuban (talk) 17:38, 12 January 2019 (UTC)
@GRuban: Completely out of date and inaccurate, unfortunately. None of the suggestions work. Adam Cuerden (talk) 17:12, 15 January 2019 (UTC)
[8]. — Racconish💬 17:34, 15 January 2019 (UTC)
@Adam Cuerden: I removed the 2 outdated links. Now the information is fine. Regards, Yann (talk) 18:14, 15 January 2019 (UTC)

Structured Data[edit]

I uploaded File:Sabena trein 1989.jpg. What I dont understand is where this 'Structured Data' comes from. I removed the caption. I dont see the information in the file code. I am used to only filling in the file description. Does this come from Wikidata? I dont see any link to Wikidata. In File:Airport city express bord 1989.jpg I dont see 'Structured Data' but still the new 'Captions' I see in the upload script.Smiley.toerist (talk) 22:14, 12 January 2019 (UTC)

@Smiley.toerist: please see "Commons:File captions", these "Captions" are a first step in a large process to structure the data on Wikimedia Commons. This is not coming from the Wikidata website(, yet) but in time there are plans to make Wikimedia Commons work better with Wikidata. All files on Wikimedia Commons now have captions. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 09:35, 13 January 2019 (UTC)
I just saw it, this was beyond my imagination... Complete mess. Wow. Just wow. — regards, Revi 11:18, 13 January 2019 (UTC)
Yes, complete mess. Apparently uploaders are supposed to just carry on, shut up, and ignore the mess, rather than expecting changes on the project where we create content to actually be helpful. -- (talk) 11:23, 13 January 2019 (UTC)
Even the h1 is still there. Shocking. Nemo 11:58, 13 January 2019 (UTC)
-1. No reason to be ironic - you made the "Description" a mandatory field during uploading, so you should at least bother to explain. Maybe it would seem less idiotic / confusing if the uploader is told, during the freaking uploading process, what type of information is expected under "Description" and under "Caption". That explanation page "Commons:File captions" right now seems just like a bodily harm to normal people who try to upload a single photo. No audio or video... Alexpl (talk) 19:05, 13 January 2019 (UTC)

Half gray filter[edit]

At the time in the non-digital world (1991) I was experimenting with a half gray square filter. The sunligth was still to strong so I wanted to reduce it on the rigth side and stil keep a normal exposure on the left side. How does one categorise these kind filters? Can this picture be digitaly corrected? (Keep the original as use for illustration). The next sunset pictures can be seen in Category:Smiley Toerist 1991 Poland trip.Smiley.toerist (talk) 23:09, 12 January 2019 (UTC)
if you had the specification on the filter you could categorize and make it easier to correct, i.e. File:Neutral density filter demonstration.jpg -- Slowking4 § Sander.v.Ginkel's revenge 17:29, 13 January 2019 (UTC)
It is a 'cokin A 123' filter.Smiley.toerist (talk) 00:03, 16 January 2019 (UTC)
here is a parent Category:Cokin filters - Slowking4 § Sander.v.Ginkel's revenge 15:04, 17 January 2019 (UTC)

January 13[edit]

"Commonswiki" links in Wikidata[edit]

Currently in Wikidata Wikimedia Commons is treated like "an ugly stepdaughter" and can only be added by clicking "Other sites" while every other Wikimedia project family has their own dedicated section, I am planning on suggesting to add a specific section for Wikimedia Commons too there (as this would also help structure the website better as Wikimedia Commons wouldn't then just be "hidden away" from novice users), as a part of my suggestion I actually want to propose the option that both "(gallery)" and "Category:" Namespaces could be linked simultaneously. Categories are the de facto main space of Wikimedia Commons. However there exists an overlap with Wikipedia articles and Wikipedia categories/Wikimedia categories, this problem could be solved by adding a “Categories on sister projects” next to the “Sister projects” list on the left-side of the screen on the “Desktop view” mode (if I had access to Microsoft Paint I would illustrate this, but there aren't such applications for Microsoft Windows 10 Mobile).

The suggestion would be that a new “Wikimedia Commons” collection of links would be created for every “Q-item” and that both “(gallery)” and “:Category:” should be able to be linked. Maybe this would also automatically add a short description to the top of every (linked) Wikimedia Commons page that States “For the gallery see…” or “For the category see…” which would make navigating between categories and galleries easier. Sounds like a good suggestion? Any improvements? --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 09:51, 13 January 2019 (UTC)

+1. AFAIK they were several suggestions to threat Commons as the main namespace, they were all met with oppositions. Good luck! Regards, Yann (talk) 10:16, 13 January 2019 (UTC)
This was one of the first questions I asked when I started to contribute to Wikidata. I still do not understand why it has not been implemented and why we have to choose between a link to the category or a link to the Wikimedia Commons page, and not both. No rationale given so far for the exclusion has made sense to me. RAN (talk) 10:29, 13 January 2019 (UTC)
I asked it before too, I think that I'll open up a request for comment (RfC) soon and will link it here. As the whole Structured Data on Wikimedia Commons thing is busy being implemented we need all the help from Wikidata they can give, a notability discussion went in favour of lowering the standards for Wikimedia Commons but it went nowhere because nothing was implemented and it was archived without follow up, guess that things need a dedicated RfC to try to change things. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 10:37, 13 January 2019 (UTC)
As I understand it, the reason for not doing this is that each Wikidata entry only links to *one* page on a different project. Having two links to the same project breaks the data model. That's also why it's under "other sites" - the Wikipedias can have a link to each different language edition, so it has its own section, but Commons would only have the one link so doesn't need a section. That's not just Commons - it's also the same for Wikispecies, Meta, and Wikidata itself. Although I like your suggestion, I think you'd get more headway if you asked 'Other sites' to be renamed to something else. Or we could go in another direction completely: we could (finally) scrap galleries here, and just use categories, in which case we only need the (existing) single link. Thanks. Mike Peel (talk) 11:58, 13 January 2019 (UTC)
So few galleries exist, that allowing to add two links would change very little. In those few cases where it matters, it's probably easier to get the gallery deleted. Nemo 11:59, 13 January 2019 (UTC)
  • Something very cool would be two links when you are in Wikipedia : one link for the corresponding category and one link for the corresponding gallery. Furthermore in a Wikipedia page instead of "In other projects" we could have a section "Wikimedia Commons" and then just below the links that are available. Example:
Wikimedia Commons
Gallery
Category

And then exactly the same thing in Wikidata, instead of put the link into the section "Other sites", we should have a section "Wikimedia Commons" and a possibility to add the both links : to the gallery and to the category. Furthermore that would solve all the issues and discussions about the relevance to create "non notable "items just for our categories. And we should also have the possibility to add those two links two times : one time in the category's main topic and one time in the topic main category (or that the both links retransmitted automatically). Christian Ferrer (talk) 18:40, 13 January 2019 (UTC)

+1 Agree with the proposal. For a concept modeled in Wikidata both Commons category and gallery just represent different views on the same object, as do different language WP articles. Furthermore let me mention that galleries are considered language dependent, so you can have one for English, one for German and 200 more. We do not have many such cases, but in principle this is possible. And you can have galleries for various purposes, e.g. Angela Merkel through the years and Angela Merkel through the colors. While Commons does not restrict the number of galleries in a category (and vice versa, the number of categories a gallery is in), this constraint is imposed by Wikidata. Both Commons gallery (P935) and Commons category (P373) have the single value constraint (Q19474404). --Herzi Pinki (talk) 03:03, 14 January 2019 (UTC)

 Update: The proposal is live at Wikidata, feel free to continue the discussion there. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 15:45, 15 January 2019 (UTC)

January 14[edit]

sort files pending review by timestamp[edit]

Is there currently a way to sort files in a category by timestamp? If not, is it possible to adapt the templates, such that these categories are sorted like copyvios are? I notice B-Bot is proposed to do this task, but I think it can be resolved by modifying templates.--Roy17 (talk) 03:20, 14 January 2019 (UTC)

See {{Copyvio}} and {{LicenseReview}}. I think it makes sense to sort by REVISIONTIMESTAMP instead of PAGENAME. These categories act as border checkpoints. Early ones should be served first.--Roy17 (talk) 03:48, 14 January 2019 (UTC)
Good idea, files could be stuck in that category forever. One way would be to sort it with PetScan, e.g., [9] will sort by upload date. There's also a "by date" sort option, but I'm not sure what it sorts by, it doesn't seem to be the last edit date. --ghouston (talk) 06:34, 14 January 2019 (UTC)
Now I see what you mean, {{Copyvio}} contains {{{category|[[Category:Copyright violations|{{REVISIONTIMESTAMP}} ]]}}}, which can also be done in {{LicenseReview}}. --ghouston (talk) 08:33, 14 January 2019 (UTC)

Broken files?[edit]

So far only come across two files with a strange issue, not sure if its something on my end that is the problem.

*File:Townsville city.jpg (no image, but there is a small thumbnail) strike that too! *File:Australian Army (A38-018) Eurocopter EC-655 Tiger ARH at Wagga Wagga Airport.jpg (thumbnail and image sizing works but only a small per cent of the image displays at full res) now works...

If this is a server-side issue, I wonder how many other files has this problem! If my end... Clearing the cache, rebooting hasn't worked! Bidgee (talk) 03:42, 14 January 2019 (UTC)

Tried the files before I posted the above, now they work as if there was no issue. This really doesn't solve what causes them to hang when trying to open the full res. Bidgee (talk) 03:45, 14 January 2019 (UTC)
@Bidgee: This appears to have been a temporary backend hiccup. You may want to follow mw:How to report a bug If it recurs.   — Jeff G. please ping or talk to me 03:48, 14 January 2019 (UTC)

Problem with File:Sv-museum.ogg[edit]

There's a saying: "to err is human, but to really foul things up, you need a computer". In this case, a bot and humans have both contributed.

This file was imported from another site by a bot, and is supposed to be a recording of the pronunciation of "museum" in Swedish by a native speaker. The original version correctly matches the name of the file, which is the singular indefinite form of the word. The problem is that the bot replaced it half an hour later with a recording of the plural indefinite form, "museer".

The bot that did this also adds pronunciation files to Wiktionary entries based on the names of the files- shortly after uploading this to Commons, it added it to the Swedish entry on English Wiktionary for "museum". Apparently no one has noticed that it was wrong for over eleven years, until a new editor removed it from the entry a few hours ago. Based on past experience, I'm pretty sure that the bot in question will add it back the next time it runs on Wiktionary, because the name matches, even though the recording doesn't.

Meanwhile, a human editor added the same sound file to the Swedish entry on English Wiktionary for "museer", where the recording matches, even though the name doesn't. I haven't checked, but I suspect this has happened on other Wiktionaries as well.

I'm not sure whether it would be better to revert to the original version and leave the file name as it is or to rename the file to match the current version. If there's some way to copy one of the versions to a new file name, that would be the best option, since both versions are correct for one form or another (the bot doesn't own the content, so the same license would apply to both as long as attribution is maintained). Whichever way is chosen, it looks like someone is going to have to go though the uses in the other wikis to fix them by hand. Chuck Entz (talk) 08:33, 14 January 2019 (UTC)

-- Tuválkin 11:18, 14 January 2019 (UTC)
-- Tuválkin 22:37, 14 January 2019 (UTC)

Coming soon to all wikis: beta feature FileExporter[edit]

Coming soon to all wikis: the beta feature FileExporter

In the past, importing files from local wikis to Wikimedia Commons was problematic: If you wanted to import a file from a wiki such as Wikipedia, its file and page history couldn’t be transferred properly. In a Technical Wishes survey on German Wikipedia, users asked for a solution to this problem.

As announced earlier, the Technical Wishes team is developing a feature that can import files with all of their history intact. It uses two connected extensions: The FileExporter runs on local wikis, where it provides an “Export to Wikimedia Commons” link on local file pages. The FileImporter on Wikimedia Commons handles all the rest. For instance, it checks if the licensing of the file allows it to be on Commons in the first place. This is done with configuration files that are maintained by the local wiki’s community.

A first version of this feature was deployed in June 2018, when the FileImporter was released here on Commons, and the FileExporter became a beta feature on a few first wikis. Since then, bugs were fixed and features were added. Among other things, imports are now getting log entries so that it’s easier to find imported files. Now, an improved version of the feature will be released to all wikis. The planned deployment date is January 16.

If you’re interested in importing local files, please give the feature a try. Even though it’s a beta feature, you can use it for real file imports. Please note that in order to get started, you need to

  1. activate the beta feature “FileExporter” on a local wiki (Preferences > Beta features, for example here), and
  2. make sure your wiki has a proper configuration file. Configuration files are maintained by each wiki's community. They define, among other things, whether a file can be exported. Exports from wikis without a configuration file are blocked. Here's more information on how these config files work.

We’re looking forward to hear your thoughts on the central feedback page! A big thanks to everyone who gave feedback so far. If you wish to learn more about the feature and its scope, please visit the project page. -- Johanna Strodt (WMDE) (talk) 12:15, 14 January 2019 (UTC)

 Thanks a lot to everyone who commented so far! For future questions and feedback, I'd like to ask you to come the central feedback page. That makes it much easier for us to keep track of feedback than monitoring discussions on different wikis (because we spread this information on many places). Thanks a lot! -- Johanna Strodt (WMDE) (talk) 10:29, 18 January 2019 (UTC)

Tracked in Phabricator
Task T214065
@Johanna Strodt (WMDE): Thank you for that. Sometimes, users upload fair use and shorter term files to Commons that could move per WP:F onto English Wikipedia or m:nfc onto other projects & languages, before or while being deleted from Commons. Do these extensions support "backwards" moves?   — Jeff G. please ping or talk to me 13:01, 14 January 2019 (UTC)
yes, making exporter reversible to create a local copy upon deletion at commons would go a way to lessen community drama. currently not a priority at commons, where the tools are not semi-automatic. Slowking4 § Sander.v.Ginkel's revenge 01:30, 15 January 2019 (UTC)
@Jeff G., Slowking4: It's not a built-in feature, but it’s already possible to manually delete the file on Commons and restore the original file on the local wiki. Both steps require admin rights. I’ve created a Phabricator ticket for the request to have this as a built-in functionality: T214065. I hope this answers your question. If you have more questions, it would be great if you'd place them at the central feedback page, as this makes it much easier for us to keep a good overview. -- Best, Johanna Strodt (WMDE) (talk)
  • @JJMC89: You're right about that. Only files that were imported after the release on Jan 16, 2019, have the tag and log entries. I've added this piece of information to our FAQ. -- Johanna Strodt (WMDE) (talk) 10:24, 18 January 2019 (UTC)
  • Yes, the logged imports can be found from the API using [10], or uploads with [11]. It doesn't look like both can be obtained together. Not quite as convenient as generator=allimages. --ghouston (talk) 04:32, 15 January 2019 (UTC)
  • @Ghouston: Thank you for pointing us to this issue. To help us investigate this, it would be great if you could describe a bit more what it is that you’d like to do and why. I’d be super thankful if you could do this on our central feedback page so we have all feedback in one place. That would be much appreciated. -- Best, Johanna Strodt (WMDE) (talk) 10:59, 18 January 2019 (UTC)
  • File:Illyrian Tribes es.svg something went wrong?
  • Another question. Is this importing the latest revision of a file, or all revisions? What about the deleted revisions? Suppose an image is non-free until 2018. Someone wants to import it in 2019. What is the standard procedure? I happened to raise a similar question a few days ago at w:en:WP:VPR#about_non-free_files.--Roy17 (talk) 03:49, 15 January 2019 (UTC)
    • File:Illyrian Tribes es.svg wasn't imported with FileImporter. (Someone should delete it, so the file can be imported correctly.) It looks like it was done as a normal page import, and those only include the file description page revisions and not the file.
      FileImporter imports all revisions. (Example with multiple revisions: File:KENV-DT 2018 logo.jpg) FileImporter won't import a file that has a revision deleted file revision in the history. If deletion and selective undeletion was used, only the non-deleted revisions are imported. You can ask an admin at the source wiki to reverse the deletion. I would suggest the following procedure: 1) Update the description page to indicate the new license and make sure {{information}} is completed. 2) Ask for undeletion. (For English Wikipedia, ask at en:WP:REFUND or the deleting admin's talk page.) 3) Import to Commons. — JJMC89(T·C) 07:12, 15 January 2019 (UTC)

January 15[edit]

Captions and UploadWizard[edit]

This is about the Upload Wizard and siblings. I'm dealing with the results of some photo competitions quite a lot for some years now. Uploading images is a complicated process especially for new, sporadic or otherwise inexperienced users. It is also complicated for many other experienced users. I have seen a lot of different erroneous results that occurred during upload, even when the form was partially prefilled by the upload wizzard. Now the UW has got a second set of descriptions, which causes an additional complication for the upload. I uploaded a single image this afternoon and failed to do it correctly: Wondering why my English description went to the caption and my German description to the information template. I did it wrong, because I did not expect a breaking change, this is a pitfall for experienced users (you never read the hints and headings after some repetitions of a stereotypical process.)

  • there is no css hack to disable the input fields for the caption as it is possible for the description, both sets use identical ids.
  • css hacks do not apply to the overwhelming majority of contest contributors.
  • in the German version the heading of the input field is Beschreibung in both cases, for the caption as well as the description (as named correctly in the English version). The German version urgently needs clear wording (3fold at least).Tracked in Phabricator
    Task T213781
  • Uploaders have to enter the same information in different formats more or less in four different places now, the filename, the caption, the description and the categories. Non-masochistic uploaders won't. I fear this will increase the number of badly described files.
  • The caption field is optional and first, the mandatory description field only second. I understand that there is a conflict, the caption in second place contradicts the meaning of caption. But when there are two very similar fields, it is a bad idea to make the first optional and the second mandatory. This order also breaks the workflow learned-by-heart.
  • Add a one-line explanation of .. allows to enter line-breaks, which is contra-intuitive, an error, whatever. one-liners shall not contain line breaks.
  • Experienced users do not use the Upload Wizzard in many cases, they feel it is slow, too inflexible, not stable enough, etc. How will they get supported so that they can add the caption in their preferred upload mechanism? If they are still cooperative?

For photo-competitions with many thousand images (like WLM) we need a smooth optimized workflow, not additional hurdles. best --Herzi Pinki (talk) 00:36, 12 January 2019 (UTC)

lazy variant to fill all fields (not my preferred one, but feasible) --Herzi Pinki (talk) 00:51, 12 January 2019 (UTC)

Moved to an extra section and pinging @Keegan (WMF): for an answer. --Herzi Pinki (talk) 01:11, 15 January 2019 (UTC)

What do we want to have in the caption? Information, that describes the depicted object, or information that describes the individual image? Would it be ok from the intended use cases to generate the caption from object information only? How will the small languages cope with many images e.g. from WLM that have the same caption, will they translate one by one? Or all identical captions within a single step? --Herzi Pinki (talk) 01:11, 15 January 2019 (UTC)

Hello! Here are a few answers to your question. a.) in an upcoming set of patches, the Caption field will indeed be a single line field. b.) The translations for the input field were community driven, and this first round was a bit insufficient. We'll do what we can to help improve that. c.) Captions are indeed optional, and we want to stress that, but we also want to make them prominent if they're going to be the preferred way of adding short multilingual information going forward (which is still a matter of debate in the community). Last year, we proposed removing the filename to reduce confusion and use a unique ID instead so that uploaders had one less thing to worry about, but that proposal was rejected by community members. d.) We're providing an API for adding captions so that users who have no interest in using the default UI for adding structured data can use a community-developed tool (and there may end up being several of those to fit different styles, including updates to existing tools like Pattypan). e.) Regarding caption use: it's ultimately up to the community to decide the best use case for them. Some discussions are currently underway with the Commons Android app to define this better for their purposes, including a proposal to use the first entered caption as the default filename. In general, our challenge right now is to find some common ground between sometimes competing interests in the community. This will be a process, but one that we aim to make as short as possible, and we intend to make some quick adjustments to captions in the coming days/weeks. RIsler (WMF) (talk) 19:08, 15 January 2019 (UTC)
I don't know what to do with captions. I always use the old simple, basic upload. My description does not show in caption File:St-Saud-Peyrouse 13.JPG It happens that I put in descriptions in 3 languages (en, fr, de) but most of the time only one. I don't want to look up names in several languages for one upload. And how to update thousands of uploaded files, copying the text from description to caption? How will that be done? Traumrune (talk) 14:27, 16 January 2019 (UTC)
Captions have an API available, which makes it possible for the community to develop tools to batch edit captions. As for Special:Upload, the Structured Data project is not currently planning to work on that form; many legacy workflows and batch uploads depend on Special:Upload and will not require any changes. Keegan (WMF) (talk) 19:43, 16 January 2019 (UTC)

Type of saw[edit]

Any idea of an appropriate category for the saw in this picture? Seems too coarse to be Category:Table saws; that term usually refers to something quite precise, used in carpentry. - Jmabel ! talk 03:04, 15 January 2019 (UTC)

Sawbenches or one of its subcats?—Odysseus1479 (talk) 04:39, 15 January 2019 (UTC)
Sawbenches sounds good, I'll leave it to someone else to get more specific. - Jmabel ! talk 06:48, 15 January 2019 (UTC)

Assaying[edit]

I'm guessing that someone who knows more about metallurgy and assaying could better describe what's going on in this photo, and add additional relevant categories. - Jmabel ! talk 06:50, 15 January 2019 (UTC)


English translation[edit]

Hi, What should be the correct English for Category:Carte d'État-Major? I found 2 translations: "Ordnance Survey map" for en-gb, and "Geological Survey map" for en-us. These are old maps made by Dépôt de la Guerre in the 19th century. Suggestions? Yann (talk) 13:01, 15 January 2019 (UTC)

Both of those name specific organisations, namely the British Ordnance Survey and the United States Geological Survey, that produce maps in their particular country. Neither would really be a suitable translation here. I wondered about "ordnance map", but the Oxford English Dictionary doesn't cite any uses other than to refer to the Ordnance Survey. My suggestion would be to use leave "État-Major" untranslated, and go for Category:État-Major maps. Alternatively, if you want to emphasise the source, Category:Maps by the Dépôt de la Guerre. --bjh21 (talk) 15:07, 15 January 2019 (UTC)
yeah, translation by analogy. more historical detail here Carte d'état-major (not translated, quelle surprise). you could also try category:French War Depot maps or category:French Staff maps. Slowking4 § Sander.v.Ginkel's revenge 20:37, 15 January 2019 (UTC)
Hi, I followed Bjh21, and created redirects. Thanks for your input. Regards, Yann (talk) 08:40, 16 January 2019 (UTC)

Copyright logo[edit]

Original (2nd, overwriting upload) 1st upload, now forked off as a new file.

How can this correct? If you look in the history there are two different picture. The upload user is named 'Tramwajeslaskie'.Smiley.toerist (talk) 14:07, 15 January 2019 (UTC)

  • I see two issues here:
  1. Both images suffer from {{watermark}}. Not a bad case of, though, and easy to fix with a simple crop, since the bottom slice of each image is probably not topical.
  2. There’s two images, the later overwritten over the first. Both apparently by the same photographer, showing the same subject, but with different compositions: not a case of a “practical” duplicate. Both were uploaded by the same user (the photographer, apparently), within a two-second interval.
I would not hesitate about reuploading the older one, but the very short interval has me wondering: It is too short to fairly say «No baksies!» (licenses are not revocable), as this could be just a mistake while uploading: We’ve had cases of this before, namely when personal photos are uploaded by mistake and quickly overwritten (on which a revdel is further appropriate), but in this case, regardless of the photographer preferring one over the other, we could/should keep both. It may also have been the case that the photographer intended to upload both and the overwriting is the mistake. (@Tramwajeslaskie: ping, although this user has not made any other contribution, ever.) -- Tuválkin 15:50, 15 January 2019 (UTC)
  • Additionally, it should be noted that the image description and timestamp as edited by the uploader matches the older, overwritten image — comparing with the EXIF date and image content of the second upload: "2013-08-15T16:50:13" v.s "|date=2013-07-05 14:42:05", tram on route 11 v.s tram on route 19. Since the uploader had at least a chance to look back on the file page several hours later and didn’t change that, it seems that this is a matter of a mistaken overwriting and that the uploader meant to contribute both photos. (A page layout showing one big image of a given subject, above, and smaller, clickable thumbnails below, including of the big image, as in our filepages with their File history sections, does resemble the page layout of BahnBilder.DE and other such trainspotting websites, although with a very different function; I think this might have confused this one-time contributer.) -- Tuválkin 16:14, 15 January 2019 (UTC)
@Tuvalkin: Requesting a split would IMHO have been much better, cf. COM:SPLIT. — Speravir – 23:00, 15 January 2019 (UTC)
  • Interesting, I never come across COM:SPLIT before. Will surely heed the advice for the nest time it’s needed. -- Tuválkin 23:10, 15 January 2019 (UTC)
  • @Tuvalkin: I agree that a split woudl have been better - these are two distinct photos and it is quite possible that the user of one or other might be interested in certain features other than the tramcars themselves, for example, the track layout. Martinvl (talk) 07:58, 17 January 2019 (UTC)
  • @Martinvl: A split was done, both photos are available. A COM:SPLIT (i.e., a way to split this while keeping both file histories complete, instead of one of them being a newly updated file) would have been preferible, in terms of wiki edit history, not of content — but, as said, I didn’t think of that possibility. Eitherway, I also did some categorization, which was lacking. I’m sure that asking for admin intervention for that would have been uneffective. -- Tuválkin 08:04, 17 January 2019 (UTC)

Gate vs. gates – help of a native speaker need[edit]

Why objects like File:Chirk Castle gates.jpg or File:Sankt Petersburg Winterpalast 2005 e.jpg in English are called gates instead of just gate? Is this because they have two wings? On the other hand, their respective categories use singular: Category:Chirk Castle gate and Category:Winter Palace's gate. Anyway, it sounds somewhat strange to me because in Polish we use brama what means gate. --jdx Re: 14:22, 15 January 2019 (UTC)

In English, "gate" can mean either one leaf, or the entrance as a whole. So it's proper to refer to the leaves as "gates" or to the entrance as a whole as "gate". The Oxford English Dictionary agrees: gate, n.1 has senses including "1. An opening in a wall..." and "6. a. The barrier itself ... used either in a pair or singly". --bjh21 (talk) 14:43, 15 January 2019 (UTC)
BTW, what is more proper: (gate) wing or (gate) leaf? --jdx Re: 15:06, 15 January 2019 (UTC)
Neither is a terribly common term. As an American I'd understand either after a moments thought, but would probably try to avoid the presuming my listener/reader would under either without context. I'd might say something like "a split gate with two parts (leaves/wings), each hinged at the outer edge". Really, though, I'd more likely refer to them as "a pair of gates" or "a pair of swinging gates" rather than use "leaves" or "wings". - Jmabel ! talk 16:44, 15 January 2019 (UTC)
I don't think "wing" is standard English for this: in architecture it usually refers to a fixed part of a building. "Leaf", while standard (at least in British English), is a specialist architectural term and not likely to be understood by a general audience. I think Jmabel's suggestion of just using "gates" is the best approach. --bjh21 (talk) 16:57, 15 January 2019 (UTC)
In Polish specialist architectural term for leaf of a gate/door/window is skrzydło which usually is translated into English as wing. BTW, winged altar has wings. Anyway, thanks guys. --jdx Re: 17:37, 15 January 2019 (UTC)
@Jmabel:How would you describe Elon Musk? I suspect as a South African, but would Nelson Mandela be described the same? What then is an African American? In America it is a euphemism for some one of African origin or ancestry. We don't describe people as Euro Americans do we? How do we describe folk like Obama, 1/2 "African American", 1/2 "Euro American", and raised in a white culture having to learn to be black.. The social structure of America which is addicted to racial classifications, in fact humans are addicted to classification, the need to identify and pigeon hole someone is endemic, and results in large scale social problems for which there is no cure. Something about pigeon holing people as Jewish American, Irish American, Italian American, German American (you never hear that one, nor do you hear Anglo American), etc rankles me. Regardless of origins or skin color, we all pay taxes. Except of you are of the 1% or so poor or that you don't earn enough income, then again we still pay taxes at least sales taxes. I was once told by a 4th cousin, "I am not an African American, I am black". It's a touchy subject caused by our need to identify, classify and discriminate. Was George Washington Carver an American Scientist and Inventor or was he a Black Scientist?. Is Russell Wilson, quarterback of the Seattle Seahawks a Quarteback of a Black Quarterback?Oldperson (talk) 22:31, 16 January 2019 (UTC)
This is way off topic about how to describe a gate. If you really want to go pick an argument about this, go to en:African Americans and you can get schooled there by the many people who will tell you that you are wrong. - Jmabel ! talk 01:11, 17 January 2019 (UTC)
This might help: Who’s Hispanic? at Pew Research. "Q. I immigrated to Phoenix from Mexico. Am I Hispanic? A. You are if you say so. Q. My parents moved to New York from Puerto Rico. Am I Hispanic? A. You are if you say so. Q. My grandparents were born in Spain but I grew up in California. Am I Hispanic? A. You are if you say so." We call Barack Obama African American because that's what he calls himself. We call Nelson Mandela South African, but if he said "Don't call me South African, call me Xhosa", then we'd call him Xhosa. Rachel Dolezal is an example of someone being transparently disingenuous, but generally everyone is given the benefit of the doubt to be called whatever they say they are. There's nothing about this that is unique to Americans, and it has nothing to do with Americans being "addicted to classification". Countries like Peru have a lot of experience with diversity, while those like Japan don't. You never hear "German American"? That's false. Of course you do, it's just that you don't hear it as often because the period of German immigration is relatively far in the past and most German Americans have chosen to be called American. Many non-white Americans are not given a free choice because of their skin color. All this information is out there for anyone curious to learn more about the topic. --Dennis Bratland (talk) 01:32, 17 January 2019 (UTC)

Wikidata RFC[edit]

In case the above link doesn't work well, I've started a request for comment regarding Wikimedia Commons site links on Wikidata at "Wikidata:Wikidata:Requests for comment/Proposal to create a separate section for "Commonswiki" links". I don't know where to properly announce it so I'll place a link here and at the proposals village pump. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 15:51, 15 January 2019 (UTC)

January 16[edit]

Demonym in category name[edit]

I wanted to create a category for media relating to w:Ben Johnson (American sprinter), but there's already a Category:Ben Johnson (sprinter). I presume Category:Ben Johnson (American sprinter) raises hackles, so... Category:Ben Johnson (sprinter from the United States)? Then move media from Category:Ben Johnson (sprinter) to a newly-created Category:Ben Johnson (sprinter from Canada) or the hackle-free Category:Ben Johnson (Canadian sprinter)? --Rrburke (talk) 16:56, 16 January 2019 (UTC)

@Rrburke: I try to follow English Wikipedia's disambiguations when they don't conflict. Why would "American" raise hackles but not "Canadian", USA's adoption of "America" in 1776 to the exclusion of the rest of North America, as well as Central America and South America?   — Jeff G. please ping or talk to me 18:22, 16 January 2019 (UTC)
@Jeff G.: Um, well, yes :) —Rrburke (talk) 20:45, 16 January 2019 (UTC)
@Rrburke: Well, as a citizen of the United States of America, I apologize for that adoption, but there's not much we can do about it now.   — Jeff G. please ping or talk to me 22:09, 16 January 2019 (UTC)
@Jeff G.: Oh, we've already forgotten about it. All joking aside, I've noticed that there are virtually no categories American _______s; they’re all _______s from the United States, and I can only assume that objection is the reason—even though in ordinary usage American unaccompanied by an adjective only ever means of or pertaining to the United States.
But is it clear that I'm trying to distinguish media associated with w:Ben Johnson (American sprinter) from media associated with w:Ben Johnson (sprinter), two different people? I feel like I didn't explain that well when I posted my query. —Rrburke (talk) 23:02, 16 January 2019 (UTC)
@Rrburke: Yes. Year of birth is also sometimes used as a distinguishing factor, especially in dynasties.   — Jeff G. please ping or talk to me 05:33, 17 January 2019 (UTC)
It may be better to put aside en.wp's way of categorizing and keep things slightly more generic on Commons. As the main cat is in the Sprinters from Canada cat, there is no special need to splice that text into the main cat name. Commons category names have a preference for being the simplest unique name, rather than a presumption that they are fully informative. If Nationality were a thing to add, then nearly every category about a person would then need it. However it would be useful to add a parent category indicating that he is African-American... -- (talk) 18:40, 16 January 2019 (UTC)
@: Hi, Fæ. So what should I call the category? —Rrburke (talk) 20:45, 16 January 2019 (UTC)
Do not have a strong view. Perhaps Category:Benjamin Washington Johnson. -- (talk) 21:01, 16 January 2019 (UTC)

@:Why would a category African American be desirable? Even that category is not accurate. There are real African Americans, people born in Africa and they are not necessarily persons of greater melanin in their skin. ex: Elon Musk (an African American). Whether Americans with African ancestors are properly called Afican Americans is a more difficult subject. In fact there are many such persons whose African ancestry stretches back to the 17th Century indentured servants, 18th Century slaves or are migrants or children of migrants from Africa, like Joy Reed. It is the need to categorize that is the problem. Is it notOldperson (talk) 19:51, 16 January 2019 (UTC)

Yes, yes, I live in London not America, so these so called "race" names appear meaningless to me. However, if someone were looking for black American sports people, being able to find them on Commons makes sense. What we aim for with category names is wording most useful to reusers internationally and in whatever is the most commonly understandable English, rather than the most technically correct. -- (talk) 20:06, 16 January 2019 (UTC)
@Oldperson: Because etymology is not definition. The term "African American" means what it means, not what some random person would like it to mean based on a differently constructed etymology. See African Americans. - Jmabel ! talk 21:27, 16 January 2019 (UTC)
I suppose that Benjamin Washington Johnson would be African American and Ben Johnson would be a Canadian of Black African Descent. World's Lamest Critic (talk) 22:01, 16 January 2019 (UTC)
I think Category:Benjamin Washington Johnson is perfectly fine. It's unambiguous, language neutral, (hopefully) non-contested, and accommodates possible future additions of material unrelated to sprinting career. There is by no means a mandate that Wikimedia Commons categories must correspond exactly to English Wikipedia articles. Other commonly used titles one is likely to use or search for could be redirected using. {{Category redirect}}. --Animalparty (talk) 23:14, 16 January 2019 (UTC)
I went ahead an boldly created Category:Benjamin Washington Johnson, with Category:Ben Johnson (American sprinter) as a redirect. If consensus favors a different category name, the category can simply be moved to a new name. --Animalparty (talk) 23:49, 16 January 2019 (UTC)

We 100% should not use demonyms: Does "Congolese" mean Democratic Republic of the Congo, Republic of the Congo, or the general region of the Congo? Does "Dominica" mean Dominica or Dominican Republic? Does "Chinese" mean the ancient Chinese empire, the Republic of China, the People's Republic of China, or Chinese culture and civilization in general? Is someone "Turkish" because he is from Turkey, a citizen of Republic of Turkey, speaks Turksih, is descended from Turks, etc.? —Justin (koavf)TCM☯ 02:31, 18 January 2019 (UTC)

I agree. However, Commons categories can't capture all of those differences. There are categories for places of birth and death, and there are categories like Category:People of Turkey which seem to be a combination of place of birth and place of residence (see Commons:Category scheme People, "Originating from or residing somewhere"). I don't think there are any categories for citizenship. Interestingly, Category:People of Turkey has been linked to an ethnic group item on Wikidata, which doesn't seem correct given how the category is defined on Commons. --ghouston (talk) 20:38, 18 January 2019 (UTC)

Washing-up[edit]

I am not finding any category for washing-up. There are some for cleaning, but it is not really the same. This is still a common activity for many people.Smiley.toerist (talk) 23:16, 16 January 2019 (UTC)

What about Category:Dish washing? Jcb (talk) 23:20, 16 January 2019 (UTC)
Thanks, I was searching with the wrong words.Smiley.toerist (talk) 23:36, 16 January 2019 (UTC)

January 17[edit]

Should 2FA become a requirement for access to rights with higher potential risk?[edit]

Some contributors may recall the security breaches a couple of years ago, where a few admin accounts were hacked.[12] This became an incentive to make Help:Two-factor authentication available for all accounts with sysop rights across all projects. Policies for whether 2FA is required and in which circumstances have been left for individual projects to decide. Though there has been past discussion on Commons, there has been no group where 2FA has become a requirement rather than advisory. For example admins who request interface admin rights frequently declare they are using 2FA, but this has not become policy.

I am raising on the Village Pump to prompt some views as to whether it is worth gaining a consensus to create a policy, rather than relying on 'norms' alone. Clearly the risk of project wide disruption that could be caused by a hacked or otherwise compromised account (such as session hijacking which would not specifically need a password to be compromised) is massively increased with Interface Admin rights, while Bureaucrat rights probably do not represent a much more serious risk than Admin rights alone.

So, given that 2FA is now well established across the Wikimedia Community, and all admins should probably consider adopting it, should we enforce a policy that 2FA is a firm requirement for access to Interface Admin rights, or any other specific rights which have a high risk of project disruption? -- (talk) 10:57, 17 January 2019 (UTC)

@: couple of years ago? That was last year. I don't think 2FA needs to be a requirement for Commons, at least not for "normal" admins. Some thoughts though:
  • I wonder who exactly can upgrade users to interface admin? Only bureaucrats, or can regular admins do it as well? They shouldn't be able to.
  • Bureaucrats, oversighters and interface administrators who are inactive for 2 months should be stripped from those rights until they return. Jameslwoodward and RP88, I'm looking at you.
  • Admins should have a ratelimit (both for edits and making changes to user rights, especially for sysopping and desysopping), regardless of 2FA.
This is not the first time I'm making that point about ratelimits, but we'll have to wait for someone to fuck up a wiki before we understand this is needed. - Alexis Jazz ping plz 12:10, 17 January 2019 (UTC)
"That was last year." <= No. That was 2016. --Zhuyifei1999 (talk) 12:32, 17 January 2019 (UTC)
See global lock log of Perhelion, Yann, and probably few others. — regards, Revi 10:47, 19 January 2019 (UTC)
It's happened more than once. When Fæ said "the security breaches a couple of years ago, where a few admin accounts were hacked", it was somewhat odd, as the same thing happened last year. - Alexis Jazz ping plz 11:28, 19 January 2019 (UTC)
Some answers, noting that the suggestion above specifically is not about forcing 2FA on all administrators, only additional group members representing greater risk of project wide damage.
  • The password hacking big incident was in 2016
  • Yes, reducing advanced rights on inactive accounts earlier than the standard sysop limit of 6 months would make sense
  • Ratelimits for changing rights makes sense. I cannot initially think of any good reason why an administrator would need to change group rights on several hundred accounts in seconds, rather than minutes. In a security emergency, fast mass action should still require the advanced level of a Bureaucrat, Steward or WMF dev to authorize or do it. But agree the case is not strong while this remains a hypothetical risk rather than based on past cases
-- (talk) 13:25, 17 January 2019 (UTC)
  • 2FA is mandatory for all interface admins per WMF‌ policy: m:Special:Diff/18418393/18694289. I support making it mandatory for bureaucrats, ckeckusers, and oversighters, but not normal admins. 4nn1l2 (talk) 13:49, 17 January 2019 (UTC)
    • Good diff, thanks. I missed that as it was only just in December. Being mandated for Interface Admin rights, does make a stronger rationale for the same level of security to apply to advanced rights with similar potential risks. -- (talk) 16:02, 17 January 2019 (UTC)
  • Firstly, I am very please to see this opened as a discussion rather than our usual practice of going straight to vote. As can be seen on the previous vote, a lot of oppose votes then were based on false assumptions/information.
  • You do not need a mobile phone for 2FA. You can install the authentication app on a PC or laptop instead. You do however need some device that you personally own and have with you.
  • You do not need to keep approving the 2FA each time (or many times) you log on. You can still tick the box to be kept logged in on this device (via a cookie). That of course requires that your device is in a safe place and/or you are logged into your device with a personal account protected by strong password, rather than using a shared account in a library or cafe.
  • Although a strong and unique password helps and should be considered essential, this isn't something the community can enforce or check. So requiring 2FA would allow the community to protect the project in the event that your password is compromised.
  • While sharing passwords with other sites (which then get hacked) is a common way that passwords are discovered and used against you, malicious software or scripts on your PC or browser can capture your password, no matter how long and complex it is, as you enter it. 2FA means that even if someone gets your password, they cannot access your account.
  • Higher priority than Wikipedia/Commons, if you use internet mail and have not enabled 2FA on those mail accounts, then you are exposing yourself to significant risk. With access to your mail account, most website's "Forgot your password" procedure enables a hacker to access pretty much all your other accounts (which they will discover by reading your mail), except if those accounts also have 2FA. So while some may claim they don't need 2FA for Commons, they do need it for mail. Once you have it for mail, then there is no reason you can't have it for Commons.
Having been through the steps myself (non-admins can request it), the instructions are pretty awful and scary so I can see why some are put off. It is unfortunately a bit more complex to setup/recover than 2FA on other websites, though no more complex in everyday use. So I would encourage that those instructions and information about 2FA be improved before expecting hundreds of new people to use it. -- Colin (talk) 14:12, 17 January 2019 (UTC)
i keep waiting for 2FA by encrypted key. and if you cannot establish strong opsec practices with strong passwords, what is the point of another insecure device? yet another technical fix to a soft human resource problem. Slowking4 § Sander.v.Ginkel's revenge 14:57, 17 January 2019 (UTC)
@Slowking4: Is there an existing discussion elsewhere about this as an improvement? Sounds like it should already be a Phab task. -- (talk) 15:29, 17 January 2019 (UTC)
m:Help:Two-factor authentication, and this seems to be the most recent,Tracked in Phabricator
Task T201784

here is an attempt at keys Tracked in Phabricator
Task T133211

don't see much opsec strategy, merely tactics. -- Slowking4 § Sander.v.Ginkel's revenge 15:49, 17 January 2019 (UTC)

I am opposed to any solution that requires someone to own a smartphone. It looks like some tablets are an option as well but I don't much care for that either: perfectly good users may not be able to buy $600 surveillance devices to be admins. Also, what happens if one of these devices gets dropped in a pool or lifted at the bus station? —Justin (koavf)TCM☯ 03:18, 18 January 2019 (UTC)

  • I am an example of an admin with no smartphone, and judging by conversations at last year's Wikimedia Conference in Berlin, there are at least dozens of us. - Jmabel ! talk 05:31, 18 January 2019 (UTC)
@Jmabel: Do you use this? How do you do it? —Justin (koavf)TCM☯ 05:35, 18 January 2019 (UTC)
  • @Koavf: While perhaps I shouldn't advertise this, no, I do not. When I'm here in the States, I do reliably have a (non-smart) phone with me, but I do not EVER text (and have reasons not to, which I'm not inclined to discuss here); when I travel abroad, I don't even bring that. - Jmabel ! talk 17:46, 18 January 2019 (UTC)
There would be no reason to travel with a smart phone. Once set up, Authy or a similar Chrome/Firefox plugin would run on any tablet or laptop with an internet connection. -- (talk) 17:51, 18 January 2019 (UTC)
@: Unless I am misreading the guideline, using 2FA by generating the codes on the same machine where you are logging in is not advised... Do you still need to buy a second device for 2FA? —Justin (koavf)TCM☯ 18:03, 18 January 2019 (UTC)
No, that seems paranoid to me. (Off topic...) If the machine you are accessing the internet with has been seriously compromised, to such an extent that you have a keylogger or similar copying your actions to a 'bad actor', then having your Commons/Wikipedia account hacked and getting blocked, will be the very least of your problems. Who cares if their Wikipedia account is hacked compared to the experience of bank fraud. Frankly if you use multiple devices and someone is targeting you in a MrRobot level of sophistication, then none of your devices is likely to be safe. One way of increasing the level of security on the same machine, would be to run a separate app/web app, or a different browser to your main one, just to generate the login codes.
When travelling somewhere not very safe, it would be best to take an old machine, or arrange a local borrowed machine, wipe it clean, and set up new anonymous throwaway accounts just for that trip. Many countries have the right to fully hack your machines on entry and may clone any data you have on them, with no guarantee that that data will be protected indefinitely from criminal use by other parties. Google it, there's better advice out there on how to protect yourself. -- (talk) 18:23, 18 January 2019 (UTC)
I'd say for truly paranoid security, running 2FA token generator on any general-purpose device with a CPU is a security risk. The truly paranoid should go for hardware token generators like yubikey. --Zhuyifei1999 (talk) 20:20, 18 January 2019 (UTC)
Further, 2FA cannot weaken your existing security. It is an additional factor. -- Colin (talk) 18:26, 18 January 2019 (UTC)
  • So, in the name of security, one’s encouraged ro tick on a checkbox to «keep this session logged in»? Truely impressive. -- Tuválkin 15:18, 18 January 2019 (UTC)
    • +1 - Jmabel ! talk 17:46, 18 January 2019 (UTC)
    • What are you talking about? As a 2FA user, that's something I never see. -- (talk) 17:48, 18 January 2019 (UTC)
  • @: How often are you required to type in your password? -- Tuválkin 20:44, 18 January 2019 (UTC)
Rarely, like once a year when the WMF Ops changes something and accidentally log me off, or when I have a new device. With a long (>20 char) randomly generated password and 2FA, it's probably a lot safer to very rarely be forced to type in your password on any device. My most realistic risk is session hijacking, but I get alerts when unexpected devices do anything new, so can (and have) log myself out of all devices as a precaution, then log back in (on every darn device separately; mental count, I'm logged in on 5 machines right now). -- (talk) 12:37, 19 January 2019 (UTC)

Special:NewItem get frozen[edit]

In the last two days, the "Special:NewItem" form get frozen, it is not possible to use it successfully. --ŠJů (talk) 23:12, 17 January 2019 (UTC)

@ŠJů: are you still having a problem? If so, could you please describe what is happening, so the development team can look into it? Keegan (WMF) (talk) 19:06, 18 January 2019 (UTC)
@Keegan (WMF): The problem continues. --ŠJů (talk) 22:54, 18 January 2019 (UTC)Tracked in Phabricator
Task T214213

January 18[edit]

Copyright question from a newbie[edit]

Hi, people. Is this image and this kind of licensed images allowed here? I read the rules and CC BY 2.0 supposed to be allowed here, but I want to make sure about it. And about the watermarking. Are watermarked images allowed here? Thanks for the help.--SirEdimon (talk) 03:48, 18 January 2019 (UTC)

@SirEdimon: Yes, we can host that image here (see Commons:Licensing#Well-known_licenses), and assuming it is the footballer (soccer player) Dallas Jaye, it would be within scope (random photos of non-notable people are generally subject to deletion). Watermarks are frowned upon, but not forbidden, see Commons:Watermarks and the template {{watermark}}. --Animalparty (talk) 04:39, 18 January 2019 (UTC)
(Edit conflict) @SirEdimon: the licence is fine in general. Unfortunately it can’t always be trusted on Flickr, so a little “due diligence” is called for. Checks to make include that the photo has original-looking EXIF (check), is not of a copyrighted artwork, toy, character, &c. (check), and the source account is not on the list of problematic users at COM:QFI (check). See also the intro at the last link. Offhand this one seems OK to me (assuming the subject is within COM:SCOPE).
As for watermarks, I think the best way to put it is that they are discouraged here but not forbidden. AIUI the issue with omitting them is that they might be considered part of the author or owner’s right to attribution. One approach is to first upload the file with the watermark, then crop or otherwise remove it so at least the original is still in the file history. See COM:WATERMARK for some discussion on the topic, but note that’s not policy. In this case the mark could be removed losslessly with CropTool; the image would scarcely suffer from losing the bottom bit. For future reference, please note also that we have a specific noticeboard for copyright questions.—Odysseus1479 (talk) 04:45, 18 January 2019 (UTC)
Thank you people, that was really useful information.--SirEdimon (talk) 05:16, 18 January 2019 (UTC)
For easily and faithfully transferring Flickr images and associated metadata to Commons, once you're reasonably sure they're legitimately licensed by the creator (see License laundering), you can use the "Share image from Flickr" option on the Upload Wizard. Another handy tool is Flickr2Commons. --Animalparty (talk) 05:28, 18 January 2019 (UTC)

Captions updates[edit]

I've posted a list of current design and bug fixes for captions following its release last week. Thanks to all who have helped report these issues and helped discuss ways to resolve them. Keegan (WMF) (talk) 20:28, 18 January 2019 (UTC)

@Keegan (WMF): what's wrong with "Structured data" being a level 1 (one) section? Wouldn't it eventually look like "File:Full page mockup of airplane file page.png" eventually? So it would be a level 1 (one) section, so there is no need to waste donated resources on a temporary cosmetic change, right? --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 22:36, 18 January 2019 (UTC)
What I know right now is that change is not a quick-and-easy fix if that's the design choice that will be made. The future of that task is still up in the air, but it's definitely worth mentioning as the header size difference on the current file page is notably different without apparent reason. The important point is that the discrepancy is known. Keegan (WMF) (talk) 22:51, 18 January 2019 (UTC)
  • It could be argued that The level 1 contents of a file page is the whole file page. But if Structured data were displayed in a separate tab, visually putting it on a “different page”, then I would be lekely to accept it as H1-level content, pending discussion. -- Tuválkin 23:13, 18 January 2019 (UTC)
  • Separate tabs are a level above page sections. But a section added for structured data should be at the same level as the other page sections, namely "File history", "File usage on Commons" and "File usage on other wikis". When additional sections are added in Wikitext, they are generally 2nd level to match those ones. I'm not sure why they are all 2nd level, since any issue of heading size could have been fixed in CSS. --ghouston (talk) 00:50, 19 January 2019 (UTC)
  • Well, this very page, the Village Pump, is one of the few which includes a wealth of H1 headings (heading level-1 sections). It’s simple to make it happen in wikitext (= Like this = or <h1>Like this</h1>), but it’s seldom done because, I think, users feel that on each regular page the only valid H1 is its very title. (I’m sure that this has nothing to do with CSS: H2 is always under H1, regardless of letter size.) -- Tuválkin 01:32, 19 January 2019 (UTC)
  • Yeah, you can add them. Although the software still doesn't encourage it: If you select "Advanced" from the edit menu, and go to the Heading drop down list, you are only offered "H2" - "H5". --ghouston (talk) 02:36, 19 January 2019 (UTC)
  • However, it's the same on Wikipedia: the usual "top-level" headings are H2. Curious. --ghouston (talk) 02:40, 19 January 2019 (UTC)
  • H1 is being used for the file name or article title. --ghouston (talk) 02:49, 19 January 2019 (UTC)
  • It is actually bad HTML to have H1 headings below H1 headings. We use H1 headings for dates on pages like this as a sloppy MediaWiki hack. —Justin (koavf)TCM☯ 05:21, 19 January 2019 (UTC)

January 19[edit]

Flickr status[edit]

All discussion appears to have ceased/ disappeared as to whether or not Flickr is purging a bunch of content in a matter of days. Looking at the new content pages I keep track of, I see that various mass uploaders have stepped up their uploading from Flickr of photos which match their favorite topics, while not bothering to upload photos from the same photostreams which are actually useful to Wikipedia articles and other sister projects, pushing this site further in the direction of resembling a topical POV exercise. I remember that Flickr purged a bunch of content several years ago and it appeared that it was okay to let lost opportunity be lost opportunity. Just wondering what's going on here.

On a related note, during that discussion, I recall implying that there was no need to bother with military photostreams because we have DVIDS. Am I getting this right that everything is going to be mirrored on DVIDS? I've uploaded military photos from Flickr because they're useful to sister projects, not because I'm looking to pick low-hanging fruit in furtherance of some contest to see who can upload the largest number of files. 90 percent or better of the military stuff I come across on here is poorly described, poorly categorized and unused or unusable by sister projects and makes Commons appear to be a propaganda mirror for the U.S. military. So can I be clear or not on the idea that I don't have to worry if military photostreams get deleted? There's still tons of stuff I'd like to upload, but I'm normally on mobile data or wi-fi, and Flickr is resource-intensive enough to mess with both.RadioKAOS (talk) 06:24, 19 January 2019 (UTC)

  • You mean that «various mass uploaders have stepped up their uploading from Flickr of photos which match their favorite topics, while not bothering to upload photos» that match your favorite topics? How dare they!? -- Tuválkin 07:13, 19 January 2019 (UTC)
  • Why should I upload pictures of, say trains and farming equipment if I don't care about trains or farm equipment? Why aren't you uploading more pictures of frogs or 18th century Swedish poets? I kid, but in seriousness, Flickr has said they will not delete CC-licensed photos, even if a user exceeds 1,000 photos, nor institutional photos from Flickr Commons: "Photos that were Creative Commons licensed before our announcement are also safe. We won’t be deleting anything that was uploaded with a CC license before November 1, 2018. Even if you had more than 1,000 photos or videos with a CC license." Since Wikimedia Commons can only accept a subset of CC-licensed files from commons anyway (CC-NC and CC-ND licenses are ineligible), this change seems unlikely to significantly affect Commons, unless non-Pro users choose to delete their images. --Animalparty (talk) 19:09, 19 January 2019 (UTC)

Can I not restore this file and can I list a category by date added?[edit]

Harry Houdini.jpg

Hello, this picture of Harry Houdini could be relatively easy to restore because the actual image is very clear though it is damaged but the category I found it in, Damaged PHotographs, says these are files that are not to be cleaned up. I don't see why it couldn't just be cleaned of the foldings and scratches and otherwise pretty much left as it is for the sake of the encyclopaedia. Also on the same subject, say I was looking through the files needing restoration category, and there is something like 12,000 files in it. Fine, but when I come back a while later, is there some way to list the newly added files first so that I am not swimming in the twelve thousand just to find a small number of new files? ~ R.T.G 10:02, 19 January 2019 (UTC)

@RTG: You shouldn't replace the image with a cleaned-up version; that does not stop you from making a copy with fixes. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 13:46, 19 January 2019 (UTC)
Aha, the image already is an edited image. Original is here on the wiki. ~ R.T.G 19:40, 19 January 2019 (UTC)

Transcriptions[edit]

I propose that we add a |transcription= parameter to {{Information}}. Please join the discussion. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 13:43, 19 January 2019 (UTC)

January 20[edit]

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

Navigation menu

Personal tools

Namespaces

Variants

    Views

    More

      Navigate

      Participate

      Print/export

      In other projects

      Tools

      In Wikipedia

      Edit links