Commons:Village pump

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

Shortcut: COM:VP

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


 

Cast iron pump with handle dated 1875 in the form of a fluted column with Corinthian capital on a profiled, square stone base [add]
Centralized discussion
See also: Village pump/Proposals • Archive

Template: View • Discuss  • Edit • Watch

Contents

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)
@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)

  • Symbol support vote.svg Support As proposer. -- (talk) 19:29, 11 January 2019 (UTC)
  • Pictogram voting comment.svg 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)
  • Symbol support vote.svg 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)
  • Symbol oppose vote.svg 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)
  • Symbol oppose vote.svg 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)
  • Pictogram voting comment.svg 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)
  • Symbol support vote.svg Support per above. Sneeuwschaap (talk) 20:32, 11 January 2019 (UTC)
  • Symbol oppose vote.svg 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)
  • Symbol oppose vote.svg 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)
  • Symbol oppose vote.svg Oppose A first and important step for Structured Commons. Let's try and help to improve it. Raymond 20:50, 11 January 2019 (UTC)
  • Symbol oppose vote.svg Oppose per Gamaliel, Abzeronow and Raymond. Strakhov (talk) 20:55, 11 January 2019 (UTC)
  • Weak Symbol oppose vote.svg 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)
  • Symbol support vote.svg 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)
  • Pictogram voting comment.svg 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)
  • Symbol oppose vote.svg 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)
  • Symbol oppose vote.svg 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)
  • Symbol oppose vote.svg 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)
  • Symbol oppose vote.svg Oppose Impossible to say better than Raymond and Multichill did. Christian Ferrer (talk) 22:48, 11 January 2019 (UTC)
  • Pictogram voting comment.svg 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)
  • Pictogram voting comment.svg 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)
  • Symbol oppose vote.svg 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)
  • Symbol oppose vote.svg 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 Symbol oppose vote.svg 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)
  • Symbol oppose vote.svg Oppose I like it. --Jarekt (talk) 03:45, 12 January 2019 (UTC)
  • Weak Symbol support vote.svg 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)
  • Symbol oppose vote.svg 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)
  • Symbol oppose vote.svg 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)
  • Symbol oppose vote.svg 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)
  • Symbol oppose vote.svg 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)
  • Pictogram voting comment.svg 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)
  • Symbol oppose vote.svg 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)
  • Symbol support vote.svg 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)
  • Pictogram voting comment.svg 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)
  • Symbol oppose vote.svg 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)
  • Symbol oppose vote.svg 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)
  • Symbol oppose vote.svg Oppose --ChristianSW (talk) 17:01, 13 January 2019 (UTC)
  • Symbol support vote.svg 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)
  • Symbol support vote.svg Support, per nom and all preceding discussions. -- Tuválkin 11:55, 14 January 2019 (UTC)
  • Symbol oppose vote.svg 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)
  • Symbol support vote.svg 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]

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)
Braveheart, think different about the short-term solutions, maybe. I certainly don't see a "majority of volunteers" saying that no lessons can be learnt. Nemo 13:01, 20 January 2019 (UTC)

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)

In watchlist and edit histories[edit]

  • User:Incnis Mrsi/uncaption.js makes captions-related edits to occupy less space. The same approach can be followed to hide them altogether, but note that the tree of elements is somewhat different between Special:Watchlist and action=history (the watchlist places autocomments deeper than history). Incnis Mrsi (talk) 14:26, 22 January 2019 (UTC)

Half gray filter[edit]

Bug 1991 78.jpg
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]

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)

Pictogram voting info.svg 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)

@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 [4], or uploads with [5]. 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).
  • 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)

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)

[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)

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.[6] 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,

here is an attempt at keys

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)

Thank you. I see the bug is also filed at T213975 and is being investigated there. Keegan (WMF) (talk) 22:03, 22 January 2019 (UTC)

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)
the point is well taken that uploads are often reflect the POV of the uploader and unused, rather than a taskflow "actually useful to Wikipedia" and other projects. if you had a category "image needed", "useful flickr image" or query, put it up, i will work it. Slowking4 § Sander.v.Ginkel's revenge 14:12, 20 January 2019 (UTC)
Isn't there a template on some Wikipedia pages that says "image requested"? We could theoretically use that. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 14:40, 20 January 2019 (UTC)
@Donald Trung, Slowking4: there are thousands of pages in Category:Wikipedia requested images. The categories aren't very user friendly to browse through, as they simply list Talk pages, and some are probably outdated (i.e. someone has already uploaded a free or fair-use image but neglected to remove the template(s)). Finding suitable images might be expedited/prioritized by making lists by date of subject (e.g. lifespan of person or year of event) and nationality, such that low-hanging fruit like pre-1923 US or pre-1955 Australian photographs could be queried. --Animalparty (talk) 20:39, 20 January 2019 (UTC)
and i am working that backlog. categories are never friendly. photos of living people tend to be dependent on subject visibility at public events. but a query of "living people without image" would be a start, you could then cut that by "reading at event", "on red carpet". Slowking4 § Sander.v.Ginkel's revenge 03:27, 21 January 2019 (UTC)
  • "actually useful to Wikipedia" is not all that Commons was about. For example, when I closely document a historic building, probably 2 photos at most are useful to Wikipedia. Commons scope for media is a lot broader than Wikipedia's. - Jmabel ! talk 18:39, 20 January 2019 (UTC)
commons is now notorious for "not playing nice" with other projects. i.e. URAA. it is become a walled garden of license purity, not the image repository with a standard of practice, that you might posit. and we see scope as the new "i don't like it", it is the scope of the admins interest only. Slowking4 § Sander.v.Ginkel's revenge 03:33, 21 January 2019 (UTC)
What does "admins interest only" have to do with it? You don't have to be an admin to import from Flickr. - Jmabel ! talk 18:28, 21 January 2019 (UTC)
Just in case you really wanted an answer to that question; Slowking4 is complaining that COM:SCOPE is applied according to the will or whim of an admin rather then any objective criteria, Oxyman (talk) 20:05, 21 January 2019 (UTC)
yeah, i see some DR's as "not in scope" which is not systematic, but random pot shots at newbies, subject to admins decision at DR. we are not surveying the content and systematically curating a consensus of what belongs and what does not. i.e. Commons:Deletion requests/File:Christophe aguiton 2018.jpg Slowking4 § Sander.v.Ginkel's revenge 16:32, 22 January 2019 (UTC)
this change seems unlikely to significantly affect Commons, unless non-Pro users choose to delete their images; sadly that's quite possible. Any non-Pro user with more than 1000 photos who wants to continue uploading new photos to Flickr will have to delete down to 999 first, even if all of those images are CC-licenced. I've spoken to a couple of friends who are intending to do exactly this, and I've possibly just encountered this in the wild by getting a Flickr 404 on the original source link for File:JamesCracknell.jpg (I was wondering if the photographer had any other shots of the same event) - the Flickr account had 1068 photos last year, but has since deleted down to 977. Sad to see all this history being lost. --Lord Belbury (talk) 15:08, 23 January 2019 (UTC)

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

Harry Houdini.jpg
Stone walls and chains do not make a prison -- for Houdini LCCN2014636908.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)
feel free to restore as a new version. the general lack of version control, and blithe overwriting is a continuing cultural problem. the largest tif appears to be 32 Mb File:Stone walls and chains do not make a prison -- for Houdini LCCN2014636908.tif Slowking4 § Sander.v.Ginkel's revenge 14:16, 20 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]

"Keep local"[edit]

When an editor has placed en:Template:Keep local on an image that is obviously eligible for Commons, and we would like on Commons, is there any clear policy for what to do? E.g. en:File:Cayton-Horace-R-Sr.jpg. Would it be OK to bring it to Commons with the exact same name, and just leave it as en-wiki's affair that they keep a separate copy locally for no reason stronger than some editor's whim? - Jmabel ! talk 01:41, 20 January 2019 (UTC)

A template on Wikipedia can't stop anyone uploading it to Commons. The template would only stop it from being deleted on Wikipedia (if such templates are generally honoured). --ghouston (talk) 02:03, 20 January 2019 (UTC)
Understood: perhaps I was unclear, but my question is whether when we want to do this we typically use the same file name, or a different one? - Jmabel ! talk 10:48, 20 January 2019 (UTC)
I'd use a different name, so that the Commons version is accessible on Wikipedia. It will start out the same, but may not stay that way. Many file names can be improved anyway. --ghouston (talk) 11:34, 20 January 2019 (UTC)
The "Keep local" template also takes a parameter for the file name on Commons. --ghouston (talk) 11:39, 20 January 2019 (UTC)
@Jmabel: enwiki's affair. As for the image in question, it has no date. It shouldn't be uploaded here without a date. - Alexis Jazz ping plz 11:53, 20 January 2019 (UTC)
there you are. just do not transfer images with a "keep local" because "deletion before collaboration" here. Slowking4 § Sander.v.Ginkel's revenge 14:06, 20 January 2019 (UTC)
@Slowking4: here's an example of why you shouldn't import files without all the info: "File:North Florida Wordmark.png does not have a source". - Alexis Jazz ping plz 14:41, 20 January 2019 (UTC)
your example looks like Template:PD-text to me, and you prove my point: why would anyone want to transfer images here, when we have a never ending cycle of deletion theater. Slowking4 § Sander.v.Ginkel's revenge 16:57, 20 January 2019 (UTC)
  • I don't usually tread in these parts but since it is one of my files that spurred the query, a quick comment. The reason I use Keep Local on all my file uploads is to enable linkage to an En-WP version of the file, and thus immunize myself from retaliatory deletion here. I couldn't care less whether Commons does or does not import a parallel file; I do care putting my work at risk to the machinations of trolls, deletionmongers, and political gameplayers, which use of Commons as a platform would do. I know whereof I speak. I've given up hope that you'll ever clean up your house -- so live in it and have a happy life. Carrite (talk) 05:20, 21 January 2019 (UTC)

New URAA discussion at Commons:Village pump/Copyright[edit]

Files that are now in the public domain in their country of origin (like the Netherlands, Germany or other countries with a protection term of 70 years after the creator's death), but still protected in the USA for several (up to 25) more years because of the Uruguay Round Agreements Act (URAA) continue to give us trouble here. For that reason, I've started a discussion at Commons:Village pump/Copyright#URAA revisited in 2019. Please have a look and contribute if you have anything to say. Also, feel free to notify other language discussion boards here (I'll notify Commons:Forum). Thanks. --Rosenzweig τ 14:28, 20 January 2019 (UTC)

Poor deletion practices[edit]

A botmaster requested deletion of several mistaken uploads via COM:CSD#G7. Solution? To create a deletion request.
A file which technically may be non-copyvio, but manifestly falls under COM:CSD#G4, is tagged for speedy. Solution? To create a deletion request (finished off by another sysop in few hours).
Now guess what the protagonist of this story—listed as one of Commons administrators—made to

which are derived from files which were hastily deleted from Commons after the {{duplicate}} tagging. No, even worse than yet another deletion request. Can we advice the protagonist to make some job other than dig into speedy deletion backlog? Incnis Mrsi (talk) 17:32, 20 January 2019 (UTC)

Hi! As stated on my user page "This user tries to do the right thing. If they make a mistake, please let them know." I always answer on my discussion page and I am quite open to suggestions and/or comments. I really don't like this "public shaming" on the village pump. If you think I'm not able to use admin rights, just request de-adminship.
Don't be surprise if there is no administrators, no OTRS agents and huge backlogs. This kind of comments doesn't help and makes our community unfriendly. --Arthur Crbz (talk) 18:04, 20 January 2019 (UTC)
An effective way to learn is to add files and deletion requests to the watchlist. I am not a fan of posting to user_talk for every minor pretext. Incnis Mrsi (talk) 18:16, 20 January 2019 (UTC)
Incnis Mrsi, Arthur is right. User talk pages are justly made for "minor" requests. The Village Pump is not. Regards, Yann (talk) 18:26, 20 January 2019 (UTC)
Agree with Yann and Arthur Crbz. Minor issues, discuss with Arthur Crbz first and see if they improve. In the case of the botmaster-requested deletion, from what I understand the uploading account and requesting account were not the same. Better safe than sorry. Incnis Mrsi, suggestion: move this section to User talk:Arthur Crbz. - Alexis Jazz ping plz 19:33, 20 January 2019 (UTC)

Translatewiki[edit]

There were some changes in the spanish translations of {{cc-by-4.0}} and {{cc-by-sa-4.0}} in translatewiki, but those templates haven't done the update, can some admin "purge" them? --Pownerus (talk) 18:30, 20 January 2019 (UTC)

What license is suitable when anonymous relatives posted hobby photographs after the death of hobby photographer ?[edit]

What license is suitable when anonymous relatives posted a trivial hobby photograph (landscape photo) as public domain, after the death of original hobby photographer ? --Clusternote (talk) 22:30, 20 January 2019 (UTC)

This file would have been deleted 20 July 2017 if you would not have replaced the PDM tag by a bogus PD license. Please don't transfer files from Flickr if they have the "Public Domain Mark" license at Flickr. Jcb (talk) 22:35, 20 January 2019 (UTC)
Thanks for reply. In other words, if a tirivial private photograph was uploaded on Flickr under the Public Domain Mark 1.0 by anonymous relatives after the death of original author, does it need the sent of OTRS ? It seems too hard task, in my viewpoint. --Clusternote (talk) 02:21, 21 January 2019 (UTC)
There's Template:PD-heirs, if applicable... AnonMoos (talk) 17:59, 23 January 2019 (UTC)

January 21[edit]

NPGallery: huge resource for public domain images.[edit]

Escalante Ruin at Canyon of the Ancients National Monument

I just discovered the NPGallery, a trove of thousands of high resolution public domain (mostly?) historic and contemporary images from the U.S. National Park Service with great detailed structured metadata. 6,600 historic photographs from Yosemite alone!. Check out this blacksmith with his wall of horseshoes, or this boreal owl in Alaska or this interned Japanese-American chemist photographed by Ansel Adams. From casual browsing, this collection includes a huge diversity of photographs: landscapes, people, architecture, wildlife, etc. as well as documents, drawings, and maps. This seems like a good job for a robust systematic GLAM-style upload project to ensure maximum data transfer, machine search ability, and minimal duplication. It looks like only about 170 images with "npgallery" in the file data have been uploaded so far. Someone want to tackle this? --Animalparty (talk) 07:19, 21 January 2019 (UTC)

I started a batch upload page at Commons:Batch uploading/NPGallery in case this falls off this page. I'm very interested but I don't have the free time until at least the end of the month. BMacZero (talk) 00:13, 22 January 2019 (UTC)

Tramline 37 in Katowice[edit]

There seems to exist a Silesian interurban tramroute 37. On the last tramline map of 2012, (File:Silesia Tramwaj Slaskie 2012.png) there is no route 37. Is there a more recent map? I hesitate to add a new category under Category:Tram lines in Upper Silesia until I am more certain of the existance of the tramline and route.Smiley.toerist (talk) 11:20, 21 January 2019 (UTC)

I now found a second picture, so I created the Category:Trams on route 37 in the Upper Silesian urban area. As this picture is from 2005, the tram route map must be incomplete.Smiley.toerist (talk) 11:41, 21 January 2019 (UTC)
@Smiley.toerist: As far as I can see from some googling, route 37 doesn't currently exist. See the map and the list of lines, which seems to agree with the plwiki list. Thanks. Mike Peel (talk) 16:51, 21 January 2019 (UTC)
It certainly existed in 2005:Smiley.toerist (talk) 00:15, 22 January 2019 (UTC)

Category:Trams on route 10 in the Upper Silesian urban area This line is not on the 2012 trammap, but on the 1974 trammap. The files are of 2014.Smiley.toerist (talk) 00:12, 24 January 2019 (UTC)

Status of featured sounds/media?[edit]

I know that FPC covers video files, but do we have any process left that features sound files? It looks like Commons:Featured media candidates and Commons:Featured sound candidates are long inactive. Does FPC cover sounds, but just rarely has any? — Rhododendrites talk |  16:49, 21 January 2019 (UTC)

How do I "replace the copyvio tag"?[edit]

We received a notice from user RonHJones that a photo we uploaded to Wikipedia might be a copywright violation. However, it is our own work. We have responded to RonHJones and explained the circumstances. The notice of possible violation states, in part, "If you believe this file is not a copyright violation, you may replace the copyvio tag with a regular deletion request." We do so believe, but we are not sure how replace the copyvio tag as we have never encountered this issue before. - Steve Beren. SteveBeren-Susan4Senate (talk) 21:28, 21 January 2019 (UTC)

@SteveBeren-Susan4Senate: Click "nominate for deletion" (under "Tools"), enter a reason why it should be deleted or kept and click "proceed". - Alexis Jazz ping plz 21:32, 21 January 2019 (UTC)
Adding to that: I know it seems perverse to remove the tag and the "nominate for deletion" in order to argue against it being deleted, but that's how to end up with a deletion discussion instead of just a one-sided decision. - Jmabel ! talk 04:58, 22 January 2019 (UTC)
  • Absolutely, and also it can be seen as «starting a discussion about a possible deletion», not always «nominating for deletion». In such cases, I find useful that the DR rationale already includes a {{vk}} warning, signed and dated by the nominator. -- Tuválkin 16:09, 22 January 2019 (UTC)

January 22[edit]

Location in Andalusia in 1992?[edit]

... and others.(File:Andalusia rail 1992 2.jpg, File:Andalusia rail 1992 4.jpg, File:Andalusia rail 1992 5.jpg) It is presumed to be in 1992. The dating is based on (File:Córdoba station 1992 1.jpg, File:Córdoba station in 1992 2.jpg, before the renovation)Smiley.toerist (talk) 00:19, 22 January 2019 (UTC)

Proposal incubator[edit]

I'm working on a concept for a proposal incubator at User:Alexis Jazz/Proposal incubator. The goals for this idea can be found at User talk:Alexis Jazz/Proposal incubator#Incubator goals.

Feedback is welcome. - Alexis Jazz ping plz 09:27, 22 January 2019 (UTC)

Copyright of 1935 Mapparium[edit]

A view of the map from the inside, also up for deletion.

The Mapparium is a three story map of the world created in 1935. The viewer stands inside the sphere, which is open to the public in Boston, USA. A recent deletion request raises some questions about whether it is still in copyright. It probably is, but can anyone find some firm evidence?

  • The architect was Chester Lindsay Churchill, born in 1891, but we have yet to find a date of death.
  • The Mapparium disallows photographs because they claim that the map is copyright of Rand McNally. Can anyone work out which map of the world was used and if it is still in copyright, when this expires?

Thanks! -- (talk) 09:36, 22 January 2019 (UTC)

There need to be a copyright notice, and a renewal to be still under a copyright. Regards, Yann (talk) 16:24, 22 January 2019 (UTC)
Two sources giving a death year of 1958 for architect Chester Lindsay Churchill: [7] (search for "Churchill" in the B/W PDF), and [8] (page 17). Lupo 14:51, 23 January 2019 (UTC)
Brief bio, albeit without death date, in [9]. Lupo 15:01, 23 January 2019 (UTC)
I can't figure out exactly which original Rand McNally map was used, but that company did seem to renew its map copyrights from that era. For example, Cartoons of world map; for use in decorating large spherical surfaces. (from 1935) was renewed in 1963.[10] DMacks (talk) 16:53, 23 January 2019 (UTC)

French departments[edit]

I have disambiguated a number of French departments, Category:Ariège, Category:Creuse, Category:Essonne, Category:Gers, Category:Landes, Category:Loire, Category:Marne, Category:Meuse, Category:Moselle, Category:Nord, Category:Oise, Category:Somme, Category:Tarn, Category:Var, Category:Vendée and Category:Vosges but others may need doing. I pointed this out at Template talk:Departments of France#Loire but the edit request still hasn't been made. The {{Departments of France}} should be updated so that it tries "Foo (department) for those and falls back on just "Foo". Crouch, Swale (talk) 13:01, 22 January 2019 (UTC)

Whack of files from the Cleveland Museum of Art[edit]

The Cleveland Museum of Art has been uploading a large number of files from its digital collection to Commons, about 3,000 over the last couple of days. The files are miscellaneous, uncategorized and lacking descriptive filenames, so they will be hard for users to locate and use. What's a good place to enlist some help? --Rrburke (talk) 14:23, 22 January 2019 (UTC)

  • great, that is their accession number, a unique identifier - filenames do not matter, when the description is in the artwork template, and findable in the search box. as long as the metadata is at wikisource, they will be queryable. Slowking4 § Sander.v.Ginkel's revenge 23:05, 22 January 2019 (UTC)
File names should be reasonably descriptive, as they are less likely to change on the whims of users. What's in the description field today may be different or gone tomorrow, such is the wikiway. Clearly there's no perfect file naming criteria that will satisfy everyone, but a balance between uniqueness, descriptiveness, and conciseness should be stressed, especially with valuable institutional uploads. Uploading only museum name and accession number is unique, but not recommended (Commons:File renaming discourages meaningless or ambiguous names, which includes "Names that are not meaningless, but do not describe the file"). --Animalparty (talk) 01:12, 23 January 2019 (UTC)
you are wasting your time whinging about file names. if you do not make uploading your file name convention easy for newbies, then it will not happen. and then much file rename drama will ensue. i find file template metadata stable; rather, the edit warring over file names is the wiki way. since the search finds the template descriptions, it is edit warring for no functional purpose. and you realize we have hundreds of thousands of files with worse file names, with no metadata, with little prospect of cleanup. Slowking4 § Sander.v.Ginkel's revenge 03:58, 23 January 2019 (UTC)
Got it, no more whinging from me. ;) --Animalparty (talk) 04:35, 23 January 2019 (UTC)
  • Hi folks, I've been helping the Cleveland Museum of Art on this project as a short-term Wikimedian in Residence, mostly on the Wikidata side but I have let them know about improving image naming for future batches. Multichill has also been in touch with them about this. As you can see they used Pattypan only using accession number in the filename, though they did supply metadata in the template. We can do a mass rename based off that, and the Wikidata items for these have the relevant metadata for categorization tasks. See the Wikidata query here [11] The upload was part of their open access project today to release 30,000 images under CC0, so this was their first upload as part of that. [12] Thanks. -- Fuzheado (talk) 16:55, 23 January 2019 (UTC)
See Category:Images from Cleveland Museum of Art for an overview of the images. Multichill (talk) 23:08, 23 January 2019 (UTC)

A word in English needed[edit]

I'm using a lot of stuff about irrigation ditches. Sometimes a ditch branches in two by using a wall along the middle of the flow. That's called llengua or lengua as it resembles a tongue, but that's Catalan and Spanish. I need a word in English. Here you can find some samples of what I'm talking about. Thanks for your help! B25es (talk) 19:38, 22 January 2019 (UTC)

  • A kind of sluice gate maybe. --ghouston (talk) 06:08, 23 January 2019 (UTC)
  • A bifurcation, perhaps? But I'm a native English speaker and I would have had to guess the meaning in the context of sluices. Thincat (talk) 21:31, 23 January 2019 (UTC)

January 23[edit]

Help with categories on Viking-related items[edit]

For three similar files I recently uploaded—File:Nordic Museum - contents of a Viking grave and other warfare-related items 01.jpg, File:Nordic Museum - contents of a Viking grave and other warfare-related items 02.jpg, File:Nordic Museum - contents of a Viking grave and other warfare-related items 03.jpg—I suspect I've fallen woefully short in terms of categories. I suspect someone who knows the subject could do a lot better, if anyone wants to try. Categories should be identical for all three photos, which are basically three slightly different ways to photograph the same exhibit. - Jmabel ! talk 04:39, 23 January 2019 (UTC)

And I'm probably even more out of my depth with some of the others for exhibits in Category:Nordic Museum, e.g. File:Nordic Museum - objects of adornment, etc., case 1 - 01.jpg. - Jmabel ! talk 05:18, 23 January 2019 (UTC)

Wiki Loves Africa 2019 around the corner : your help more than welcome[edit]

Hello everyone. In less 2 weeks time, the latest (5th) edition of Wiki Loves Africa will launch on the theme Play for one month. Please check out the contest main page for details about the theme if you are directly interested and want to contribute pictures and join the fun online or locally.

But this message is also a pre-warning that hords of new and unexperienced users from Africa will join and upload pictures, that are often wonderful (but not really categorized or described) and sometimes terrible (blurred, irrelevant, promotional, copyrighted etc.). I would like to extend an invitation to you guys to help with image tracking and clean-up during the contest. If you plan to help heavily, please add your name to the team page so that we know where to go and who to ask if we have issues. But also, more generally, please help in keeping an eye on the where images will be uploaded (right now there is only a test picture from a painting from my daughter... but soon... we can expect probably around 10k images to look at). Your help will be tremendously and gratefully welcome.

Anthere (talk) 13:53, 23 January 2019 (UTC)

Damaged photos[edit]

My apologies if this has been discussed elsewhere. Working on deletion requests, I see a lot of damaged photos, where upload looks like incomplete. I do not have an example of a survived photo, since they are always deleted, but for example this delete photo, File:ВОДОБОЙКА.jpg, was clearly broken. Does anybody know what the reason for these is. Are they really broken uploads, where the uploader did notice that the upload has been incomplete, or were they regularly and properly uploaded photos which became broken because of a server glitch or smth similar? In the latter case, we probably need to check our own photos and reupload.--Ymblanter (talk) 15:52, 23 January 2019 (UTC)

This is a fairly common problem—see Incomplete digital photographs—but it isn’t always due to a server malfunction. If the TCP connection dies mid-upload, then MediaWiki stores the portion of file it received. Incnis Mrsi (talk) 16:23, 23 January 2019 (UTC)
Thanks. Are you basically saying that incomplete photos are always due to incomplete uploads (and failure of the uploaders to check the quality of the upload)?--Ymblanter (talk) 16:33, 23 January 2019 (UTC)
I say that there are reasons for a file to be stored incompletely. One of these is related to cross-wiki upload forms (see phab:T201379) and is perceived as a bug, but a truncated file may arise from a (premature) client TCP failure, and this latter is indeed a feature. As for “failure of the uploaders to check the quality of the upload” – of course, but we are in the wiki, Yaroslav, and you don’t really expect quality anywhere, it’s a rhetorical device ☺ Incnis Mrsi (talk) 16:41, 23 January 2019 (UTC)
This is fine, I just wanted to make sure that if we do check the quality of the upload, the photo us guaranteed (barred some commonly unexpected events like Ragnarök or a North Korean missile hitting the servers) to stay in the same quality it was uploaded.--Ymblanter (talk) 16:48, 23 January 2019 (UTC)
This should not be possible to happen. Uploads go to the UploadStash. Only after an upload is complete the file is actually published and then removed from the stash. If an upload breaks, before the file is completly uploaded, you can go to Special:UploadStash, identify the file in question and then go on with the upload (provided the file size is less than 1(?) MB. --C.Suthorn (talk) 17:11, 23 January 2019 (UTC)
@Ymblanter, Incnis Mrsi, C.Suthorn: See also the 5MB crosswiki upload cutoff bug.   — Jeff G. please ping or talk to me 18:26, 23 January 2019 (UTC)

Bulk downloading images from databases[edit]

Black and white photograph of a gold death mask resembling a human face
Colour photograph of the Vendel 1 helmet
Vendel 1 helmet

A number of the files that I've uploaded—two examples are shown here—come from much larger databases that contain licenses appropriate for use on Wikimedia. The Vendel helmet, for example, is part of the Statens historiska museum, which uploads photos of its collection with a CC-BY license. The gold mask comes from the w:Hyper Articles en Ligne database, which licenses files under a licence ouverte. Other databases have similar policies—files from the Portable Antiquities Scheme, for example, are available under a CC-BY-SA license.

It seems that some databases, such as that of the Metropolitan Museum of Art, have been uploaded in bulk here. Is there a way to suggest similar action with respect to databases such as those described above? Thanks, --Usernameunique (talk) 19:11, 23 January 2019 (UTC)

@Usernameunique: Yes, please see COM:BATCH.   — Jeff G. please ping or talk to me 19:22, 23 January 2019 (UTC)

Getting CC BY, CC-BY-SA and ODbL data on Commons[edit]

Hi all

As some of you might remember a year or so ago there was agreement that Commons would host open license data (expanding from only hosting CC0 data). This would mean that many data repositories could be used including map data from OpenStreetMap. Unfortunately there are still a few technical barriers to cross before this happens. If you are technically inclined and you'd like to help here is the Phabricator task:

Thanks very much

John Cummings (talk) 21:12, 23 January 2019 (UTC)

Filter images by weight, byte, or by quality?[edit]

Is there any way to filter images by weight, bytes, or by quality?MONUMENTA Talk 22:46, 23 January 2019 (UTC)

You can use PetScan to sort a category in order of file size, e.g., [13] will give the 100 biggest from Category:Felis silvestris catus in order of descending file size. --ghouston (talk) 23:03, 23 January 2019 (UTC)
--ghouston, how have you done to order them from largest to smallest size, bytes?MONUMENTA Talk 00:51, 24 January 2019 (UTC)
By ticking the boxes in the Output tab to sort by file size and descending. --ghouston (talk) 00:56, 24 January 2019 (UTC)
Thank you very much --ghouston.
MONUMENTA Talk 01:38, 24 January 2019 (UTC)

January 24[edit]

Converting .avi and ,mp4 files[edit]

I have an .avi and mp4 file. Uploader rejected because of file format. I downloaded and installed Wondershare Video converter. I thought I had converted the files to .ogv format but they still have their .avi and .mp4 format. I know that they will be rejected if I try to upload them in that format. Can I change the extenstion to .ogv and still upload them?Will they play. I am stymiedOldperson (talk) 00:31, 24 January 2019 (UTC)

No, you cannot. Videos have to be of filetype Ogg Theora or WebM, and this is checked. You should test other converters if the Wodershare thingy does not really convert the files (or it does, but do not change the file extension?). I myself love XMedia Recode, but its working approach is first hard to understand. You could also check out MediaCoder. — Speravir – 03:02, 24 January 2019 (UTC)