Commons:Village pump

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

Shortcut: COM:VP

↓ Skip to table of contents ↓       ↓ Skip to discussions ↓       ↓ Skip to the last discussion ↓
🌐 Village pumps for other languages
COMMONS DISCUSSION PAGES
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; the latest archive is Commons:Village pump/Archive/2024/08.

Please note:

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

Purposes which do not meet the scope of this page:

Search archives:

   

Start a new discussion

# 💭 Title 💬 👥 🙋 Last editor 🕒 (UTC)
1 Further dissemination of Wikimedia Commons Atlas of the World needed 54 9 Adamant1 2024-08-29 03:11
2 Add "Upload file" link for mobile? 25 12 Nakonana 2024-08-28 12:36
3 Flickr2Commons 29 10 A1Cafel 2024-08-27 16:02
4 Categories related to war resisters 9 3 Una tantum 2024-08-27 17:18
5 Is renaming categories with an English name to local language names a good idea? 58 13 Broichmore 2024-08-31 13:26
6 Marking with NowCommons 6 3 MGA73 2024-08-25 13:25
7 Category:Videos by subject 10 4 Prototyperspective 2024-08-27 16:52
8 Uncategorized categories again 12 7 Jmabel 2024-08-25 18:38
9 {{Large image}} 6 4 Bawolff 2024-08-28 17:15
10 Crop Tool, again 9 4 Wouterhagens 2024-08-28 18:58
11 Rename ship 7 4 Jmabel 2024-08-27 19:21
12 Category subtree Category:Floor plans of churches by country 6 3 Jmabel 2024-08-25 18:45
13 Can I upload bt2020nc/bt2020/smpte2084(PQ) HDR AVIF images to commons and use them in wikipedia articles? 4 2 PantheraLeo1359531 2024-08-27 06:07
14 Signature on Japanese woodblock 8 6 Adamant1 2024-08-27 03:16
15 Debugging screenshots 12 4 Klein Muçi 2024-08-28 08:18
16 JPEGs versus PDFs for multipage scans 5 5 Samwilson 2024-08-27 11:34
17 How to handle poorly-created gallery pages that are the main target of the interwiki links? 39 13 JopkeB 2024-08-29 14:52
18 Thank you to all the 2024 Summer Olympics photographers! 4 3 FreCha 2024-08-31 12:03
19 Massive backlogs are now the norm 24 12 JopkeB 2024-08-28 06:36
20 Category for "buses in" and "buses of" 9 3 Infrogmation 2024-08-28 20:52
21 Reredos or reredoses? 8 4 MGeog2022 2024-08-31 12:28
22 Toilet type 2 2 Adamant1 2024-08-27 22:52
23 Is File:P103013PS-0384 (10596687253).jpg actually PD? 2 1 Jmabel 2024-08-28 00:44
24 Uncategorized categories, except infobox 17 3 Enhancing999 2024-08-31 10:03
25 Category descriptions 24 10 Omphalographer 2024-08-31 06:15
26 French summer camp 9 5 RZuo 2024-08-31 00:03
27 Two-sided image 4 4 Jmabel 2024-08-29 18:56
28 When questioning "own work" 7 5 DaxServer 2024-08-31 17:57
29 inconsistent database state 19 4 Zache 2024-08-31 12:49
30 Old version of the picture should be a separate file 6 4 Broichmore 2024-08-30 12:36
31 How to deal with an svg image that has rendering problems 4 2 Enhancing999 2024-08-31 10:14
32 Disambiguating categories 4 2 Adamant1 2024-08-31 02:22
33 Deletion category update as a step in closing DRs? 11 4 Jeff G. 2024-09-01 00:35
34 Upload via OpenRefine: how to include the "description" for the Information-Template 4 3 CalRis25 2024-08-31 10:48
35 Check copyright and remove if necessary 3 2 Mário NET 2024-09-01 03:18
36 Native American fishing rights 1 1 Jmabel 2024-09-01 02:57
Legend
  • In the last hour
  • In the last day
  • In the last week
  • In the last month
  • More than one month
Manual settings
When exceptions occur,
please check the setting first.
Women at the well, India, early 20th century. [add]
Centralized discussion
See also: Village pump/Proposals   ■ Archive
Template: View   ■ Discuss    ■ Edit   ■ Watch
SpBot archives all sections tagged with {{Section resolved|1=~~~~}} after 1 day.

August 31

Glam project - Derivative works of Picasso works

Please someone very expert, better with an otrs flag, could express his own opinion on this Commons:Deletion requests/File:Paolo Monti - Servizio fotografico (Italia, 1958) - BEIC 6341427.jpg. --Pierpao.lo (listening) 09:10, 24 Septem

Input requested on 3D object file upload process

Commons,

As discussed previously, there are a few legal concerns regarding enabling 3D uploads. Particularly around uploading patented objects or objects that are weapons. The legal team at the foundation has given input and the designers have created a prototype of how the upload process could consider this language.

We'd like to get some community feedback on this before going forward. Please take a look at the interactive prototype and let us know of any concerns or unaddressed issues. This prototype shows messaging regarding both 3D patented files and 3D files that are of a weapon.

https://wikimedia.invisionapp.com/share/7VDBAJVSN#/screens/251552642_0

Yours (again), CKoerner (WMF) (talk) 22:17, 4 October 2017 (UTC)[reply]

Looks okay, let's get on with it. If someone uploads a 3D printable gun, I guarantee a volunteer will happily delete it within literally seconds, rapidly followed by an account block. I'm looking forward to lots of 3D models of notable antiquities. --Fæ (talk) 10:04, 5 October 2017 (UTC)[reply]
@CKoerner (WMF): I +1 Fæ. :) --Steinsplitter (talk) 13:32, 5 October 2017 (UTC)[reply]
CKoerner, I would submit that, typically, whoever uploads a 3D file and declares that the "use of this file and any 3D objects depicted in the file will not infringe any patents" and grants a "patent license" declaring that "any 3D objects depicted in the file are [their] own work" is, with respect, a complete nut job. One of the many nice aspects of copyrights is that while there are many, many ways to infringe them, it is also really easy to not infringe them. As the painter of an oil painting, I can easily give you the assurance that my painting doesn't infringe anyone's copyright (nowhere in the world), and I can easily assure you that - from a copyright perspective - you are free to use it. On the other hand, if I design a plastic cup, I have absolutely no clue whether it may somehow incorporate an invention that is patented by someone, somewhere. Could it be a disposable beverage cup having a planar base, a substantially frusto-conical sidewall extending and widening from said base, terminating in an opening having a rim, and being centred on a longitudinal axis for said cup, wherein said sidewall has corrugations throughout the entirety of said sidewall, from said base to said opening, and wherein said corrugations are formed from a plurality of projections and depressions and extend circumferentially around the entirety of said sidewall except where corrugations terminate at said base and said opening, and wherein the entire outermost edge of each of the projections of the corrugations lie in a corresponding and different one of a plurality of straight, parallel, and non-intersecting planes that are tilted relative to said longitudinal axis, provided that the tilt is less than 90° (US 9,351,596)? Or is it a reinforced cup protected by US 8,622,208? Or a reinforced plastic foam cup protected by US 7,814,647? How about Japanese patents? Where do I even find Japanese patents? The proposed wording creates a massive liability risk for uploaders. What if I upload my cup design and a Japanese producer decides to put it into mass production? If that cup violates some Japanese patent and the producer gets sued, they'll sure be happy to trot out my "patent license" and try to pass along the bill. And, and that's the difference to the copyright case, I can basically do nothing to eliminate such a risk. Even non-tech companies spend vast amounts of money trying to identify conflicting patents. (I used to intern at a patent law firm: At the earlier stages of development, companies would routinely limit the research to a very small set of key markets to keep the costs in check.) Then how is your run-of-the-mill free knowledge enthusiast supposed to do that? I believe what you propose is unnecessary with respect to the Wikimedia Foundation's own liability risk, and your "Wikilegal" document seems to agree. At the same time, because the idea that an uploader has conducted a patent due diligence for the objects depicted in their 3D files is absurd, their declaration to that effect is practically worthless for any user; however, should anything go wrong, it is an invitation for any patent infringer to raise claims against the clueless uploader. It sure seems desirable to ban uploads of 3D files depicting knowingly patent-infringing (including soon-to-be patent-infringing) material so as to prevent uploaders from essentially setting up "IP infringement honeypots." But having the uploader give the additional assurance that arbitrary users throughout the world will not infringe any patent if they print the object doesn't appear to me to be a particularly fair approach. — Pajz (talk) 16:10, 5 October 2017 (UTC)[reply]
+1, and very well put. - Jmabel ! talk 20:01, 5 October 2017 (UTC)[reply]
I think all these words boil down to adding "knowingly" to the statement and then making that visible for reusers, along with a visible process for take-down if patent trolls claimants want to try it. --Fæ (talk) 20:11, 5 October 2017 (UTC)[reply]
"IP infringement honeypots." = i love the appeal to fear, and the patent purity. you realize there is a free-wheeling 3D printing community out there, which you are choosing not to collaborate with, because they will not check off some free software ideological box? Slowking4 § Sander.v.Ginkel's revenge 12:42, 10 October 2017 (UTC)[reply]
Of course 3D and 2D are substantially different, which is why for instance we have PD-Art, Commons:BEIC probably can have enough copyright on 2D photos of 3D objects, etc. However I'm quite confident that Commons will be fast and efficient enough at deleting questionable uploads. I think this kind of feature is most likely to be used on some niche Wikipedia articles or some Wikibooks books about chemistry and similar, where this technology can give Wikibooks an advantage on some competing OER websites. Nemo 06:45, 11 October 2017 (UTC)[reply]
Thanks all for the thoughtful comments. I've passed them along to the product team and legal for consideration. I'm still listening. :) CKoerner (WMF) (talk) 16:25, 12 October 2017 (UTC)[reply]
Thanks for the comments, all. I've taken a look at the suggestion from WMF legal, and what we'd like to do is use phrase "knowingly or recklessly" in the license to address the case of somebody accidentally uploading something without realizing that a patent exists out in the world. The reason that "recklessly" helps there is that both "knowingly" and "recklessly" are legal jargon, and "knowingly" doesn't quite cover all the cases we'd want. In particular, an editor who grabbed a bunch of stuff they don't own and uploaded it all might be acting "recklessly" while causing everyone patent removal headaches, but since they haven't actually checked a patent database, that probably wouldn't be "knowing." What we'd like is for people to see the screen and stop and think to themselves for a second as to whether somebody might own an invention being depicted in the file. It's okay if a mistake happens, but making sure that the confirmation includes "knowingly or recklessly" would cover the abuse cases. I want to post that here to get some thoughts on it and see if there are any concerns with that language. -Jrogers (WMF) (talk) 19:48, 19 October 2017 (UTC)[reply]
Jrogers (WMF), sounds reasonable. I would suggest you remove the term "Patent License" accordingly. (By the way, while my comment focussed on appeared to me to be the most pressing issue, I don't really get the second section of that box anyway. It says "Patent License" in the heading and below it says "Any 3D objects depicted in the file are my own work". How is that a license?) Best, — Pajz (talk) 07:57, 20 October 2017 (UTC)[reply]
@CKoerner (WMF): I think the "Patent rights" dialog box is inconsistent with the look and feel of the "Release rights" step, and could be incorporated under "This file is not my own work" on that step. The checkbox could be eliminated by replacing "Next" with "I agree".   — Jeff G. ツ 02:57, 20 October 2017 (UTC)[reply]

October 05

Object location data being hijacked away to Wikidata

I noticed these two edits today in my watchlist, and that means that there’s hundreds of these going on. I don’t like this one bit and will revert on sight. Geolocation is important curatorial data that should not be stored elsewhere and whose curation should not be outsorced. (I have no qualms of pairing our geolocation with Wikidata’s; differing values have been found in the past and their reconciliation has been both useful for both projects and instructive to all.) Any opinions?— Preceding unsigned comment added by Tuvalkin (talk • contribs) 12:55 5 oct 2017‎ (UTC)

Coordinates are fetched from Wikidata item now. Why do you consider this to be a problem? After all this allows to reduce duplication of coordinates in different images of same object and possibility to correct them in one place. Of course, vandalism is not excluded, but vandalism is not something new in WMF projects. --EugeneZelenko (talk) 14:02, 5 October 2017 (UTC)[reply]

These changes need to be reverted. @Jarekt: please stop your bot changes immediately and re-introduce the coordinates, or I shall be forced to request a block on the account. You do not have a community consensus to remove the text-searchable geo-coordinates from Wikimedia Commons. Wikidata is a support tool for this project, it does not mean that all our searchable metadata is fair game for being erased.

... Jesus, I've now checked the history. All the geo-coordinates have already been speedily erased by Jarektbot using AWB. Can someone reassure me that there was a Wikimedia Commons community consensus to do this in advance? --Fæ (talk) 15:01, 5 October 2017 (UTC)[reply]

This should not be happening if we are losing useful information such as Scale:, Region: and I think it should stop until this at least is resolved. Rodhullandemu (talk) 15:06, 5 October 2017 (UTC)[reply]
Sorry, we don't get a say. Based on the evidence, Jarekt has made the decision on behalf of the rest of us, though maybe there was a discussion on Wikidata somewhere and we didn't get invited. So now, if we are "power users" we have to be active on Wikidata and use all the special cryptic SPARQL "Q-based" tools there, rather than doing our thing on Commons. I'm waiting for someone to provide a link to prove that my assumptions are bad faith rubbish... --Fæ (talk) 15:12, 5 October 2017 (UTC)[reply]
Coordinates of places are stored on Wikidata and are being used by us and other Wikipedia projects. It is nice if locations we have correspond to locations used on Wikipedias. If they are than our local copy is redundant and rather unnecessary and it would be preferable if future changes are made to the master copy instead of the local one. The removal of redundant copy does not change the look of the pages or the machine-readable data. I am more interested in cases where our coordinates do not match coordinates used by others, as with pages in Category:Pages with local coordinates and mismatching wikidata coordinates. In such cases we should correct either our data or data on Wikidata. --Jarekt (talk) 15:24, 5 October 2017 (UTC)[reply]
Jarekt, revert the blanking of geocoordinates immediately. You introduced location "Q" numbers (which by the way, are meaningless to us Commons power users) and then as a second set of mass changes decided to remove the geo-coordinates from Commons altogether. If you want to remove Commons geodata, making all our pages entirely dependent on Wikidata and Wikidata based tools to run the most basic geo-based searches and analysis, you must get a Wikimedia Commons consensus first. The changes are controversial, as evidenced by the fact that I am here making a huge fuss about it. If you want to make a case and explain to me and others why the metadata on Commons is "redundant", you can do that in a proposal on this project.
If you refuse to do this I shall ask for a block against your bot account and mass revert your changes myself. I'd much rather not waste more of my time and see you comply with standard norms of collegiate behaviour on Commons. Thanks --Fæ (talk) 15:29, 5 October 2017 (UTC)[reply]
"Redundant AND unnecessary"? Where has this been discussed on Commons ("nice" doesn't override consensus in my view), and are parameters such as Scale: supported on Wikidata? "Rodhullandemu (talk) 15:30, 5 October 2017 (UTC)[reply]
@Jarekt: This was deletion without consensus or adequate contemporaneous explanation on a massive scale. Kindly revert those changes immediately.   — Jeff G. ツ 15:59, 5 October 2017 (UTC)[reply]
(Edit conflict) The rendered page is exactly the same, only loads a bit faster because the template does not have to reconcile multiple versions of the coordinates. Two locations to store the same data, serves no purpose, and is just confusing. Others are removing those coordinates, like in Category:Abbaye de la Victoire for example, so I though I would help with non-controversial locations which are the same here and on Wikidata. That way it is easier to concentrate on the real issue of the locations that do not match and should be reconciled. --Jarekt (talk) 16:02, 5 October 2017 (UTC)[reply]
@Jarekt: Last chance. Please revert your changes and make a proposal to the Commons community. Any reply from here on without taking these steps I'll have to read as a refusal to work collegiately and I will be requesting at AN that your bot is blocked, the flag removed by a 'crat due to misuse, and I'll create a script to revert the changes (probably tomorrow as I have better things to do today). --Fæ (talk) 16:09, 5 October 2017 (UTC)[reply]
 Kommentar While I agree consensus is important, I don't see a problem with the changes made. Having the same information in multiple locations is not what we should strive for. It makes maintenance a pain since the same information has to be updated in more than one location and in the cases were a editor isn't familiar that the information is in more than one location you then end up with mismatching data which requires more maintenance of the data to figure out which is more correct. Commons will eventually be all structured data and all the information we can move to wikidata we should to help with the transition. - Offnfopt(talk) 15:57, 5 October 2017 (UTC)[reply]
It is precisely because of comments like "Commons will eventually be all structured data" that we must require proposals for any mass changes like this. It is not acceptable to be unable to examine Commons wikitext using tools or bots for simple metadata like coordinates that were populated here, and instead be forced to use several steps and additional tools just to examine the same data. Few users are that worked up about geocoordinates, but when we find dates , authors, licenses etc. all crazily encrypted to Q-numbers and only visible in html browser returns and invisible to basic searches on Commons, Commons will rapidly unravel as a working community. --Fæ (talk) 16:02, 5 October 2017 (UTC)[reply]
@Offnfopt: We need API access to geocoordinates and any other data that moves to Wikidata, in a manner similar to or better than API access to Commons was before Wikidata came along, with consensus, notice, and testing, otherwise stuff starts breaking. @Fæ: What has already broken (or is about to break) from your POV?   — Jeff G. ツ 16:09, 5 October 2017 (UTC)[reply]
I cannot really forecast what these changes are breaking, there are many housekeeping talks and older scripts that will be unusable if geocoordinates are suddenly not allowed on Commons or may be subject to automated removal without warning. Most of my past geocoordinate stuff I've half forgotten about, but it would be possible to brush them up without too much effort before these changes, but enough work that I'd never bother if it means I have to plug in Wikidata API calls everywhere. Right now, if I want to discover which place categories have geocoordinates within a given area I now have to both use Commons wikitext searches and write a freaky script to query Wikidata in a way I have never done before (I have no idea how to find the "nearest" Q-coded place number matching an overly high resolution digital geocoordinate that we would find, say, on the Library of Congress records for an image without writing an awful lot of clever code). There's no solution being suggested to these issues you'll note, and Jarekt has not attempted to explain how we can do mass changes, say in VFC or Pywikibot, without each of us spending several days getting up to speed on Wikidata. It feels like we are being forced to work for Wikidata as unpaid test subjects, or resign from the project. --Fæ (talk) 16:26, 5 October 2017 (UTC)[reply]
There's potentially a lot of scope for leveraging information in Wikidata to do work on Commons, so let's see if we can come up with some good example queries and code snippets to try to make the path a little less steep. (Perhaps worth a dedicated project page somewhere here). I think the prospect may be there for building some quite interesting power tools that draw on both sources, as well as everyday useful queries, and also (potentially) categorisation assists.
To kick off, here's a query that looks for items with Commons categories that Wikidata currently knows about, located within 1 km of the Arc de Triomphe in Paris: tinyurl.com/y9ozt2aj. As well as being able to run it directly, it's also pretty straightforward to run and consume the results of such queries from code. The query can of course be modified in all sorts of ways, eg to search down the administrative hierarchy if preferred, or to put in specific coordinates to use for the centre, rather than particular co-ordinates.
No, this isn't going to solve the issues with Fae's legacy code, or automatically bring hir enlightenment. But a library of examples and fragments could help us to do some quite useful things, I think. Jheald (talk) 18:18, 5 October 2017 (UTC)[reply]
Also, the same list, now sorted by distance: tinyurl.com/y77hhn9v Jheald (talk) 18:24, 5 October 2017 (UTC)[reply]
The easiest way to make mass changes in Wikidata is the Quick Statements tool: see d:Help:QuickStatements for an (evolving) page about it. Essentially this tool lets you specify up to about 6000 changes in a TSV format file, drop it on the tool webpage, and the tool goes away and does them.
This makes it easy enough for anyone to make such changes, without even having to be a "power user".
Pywikibot, I believe, has full integration with Wikidata and lots of calls are available (though, thanks to QuickStatements, I don't think I've ever had to use it).
Appropriate plugins for VFC would be an exciting thing -- eg perhaps guided/suggested addition of sitelinks / P373 "commons category" statements. More of these links probably are the single class of things currently most needed to improve inter-working drawing on both Commons and Wikidata. Jheald (talk) 18:38, 5 October 2017 (UTC)[reply]
@Jheald: I refuse to engage on hypothetical solutions to a problem that does not need to be created. This situation is like pushing someone over in the street in order to get them to buy insurance. This is not going to change, and you know full well that you need long term Commons contributors like me to both understand and support these sweeping changes to the fabric of Wikimedia Commons if you actually want them to roll out.
The first thing that needs to happen here is that Jarekt's mass changes, made with zero community consensus, must be reverted. Only then can we talk about whether this is a good thing or what the ramifications might be. The changes are disruptive and if Jarekt were not an admin here, his accounts would be blocked by now for the disruption caused.
Every hour that passes with this arrogant disregard by Wikidata advocates ignoring the most basic principles of working collegiately with Commons regular contributors is burning up any social capital that used to exist. Once it's gone it will take a hell of a lot more work to get users like me on board with your Wikidata-is-everything proposals, in fact today I have absolutely no interest in digging out my past Wikidata experiments with Pywikibot or investing my unpaid volunteer time researching new methods, whereas yesterday you may have managed to talk me into testing something with little resistance. --Fæ (talk) 19:11, 5 October 2017 (UTC)[reply]
I was merely trying to highlight some of the opportunities that inter-working with information on Wikidata and information on Commons has the potential to provide.
With regard to the co-ordinate data, I think there are a few things to say: (i) it's very valuable to make sure that the data on Wikidata and the data on Commons agree, otherwise something is likely to be very questionable about one or the other; (ii) in the longer term, it may make sense to systematically de-materialise the co-ordinate data from Commons, draw it almost entirely from Wikidata; (iii) but (at the very least) this only is worth considering if/when what is at Wikidata can match what is at Commons wholescale, to remove any necessity to duplicated searches in both places. As a prerequisite, before we can even approach that, it would be a very useful goal to get to a state where any category with co-ordinate data here has a corresponding substantive item on Wikidata. But we're currently a long way from that. So, for the very strong reasons of (a) not breaking existing tools, and (b) not forcing searches to be duplicated, I think that it makes perfect sense for User:Jarekt's edits to be rolled back.
And perhaps, if/when this is done, I can naively hope that tomorrow (or, after not too many tomorrows, at any rate) you might again feel like having a play at seeing what wonderful new things you might dream up and be able to create. Jheald (talk) 19:38, 5 October 2017 (UTC)[reply]
Good job Jarek. Keep up the good work. Multichill (talk) 20:24, 5 October 2017 (UTC)[reply]
Wikidata queries are more powerful, than manual parsing of wikitext (which may be ok for such simple task, but leads to many problems when data is even slighlty more complex). Learning of something new is not so scary, the only real problem here is tracking of changes (as far as I know, that feature poorly worked now). — Vort (talk) 05:15, 6 October 2017 (UTC)[reply]
By the word, Russian Wikipedia and Wikisource gradually remove data from templates with duplicates Wikidata in cases like personalities, settlements (including coordinates), etc. --EugeneZelenko (talk) 14:06, 6 October 2017 (UTC)[reply]

@Jarekt: Why does the Q-code need to be specified in the template? Can it not pick it up from a site link? --ghouston (talk) 22:57, 6 October 2017 (UTC)[reply]

Sorry for dropping the subjet here then apparently disappear (even forgot to sign!). All points I could have made are being made by Fæ, anyway. This discussion has revealed how much Wikidata is seen by its peddlers and their backers as a tool to break Commons. -- Tuválkin ✉ ✇ 08:42, 7 October 2017 (UTC)[reply]

It'll be good idea if you'll try to comprehend purpose of both projects. By the word, Creator templates rely in big part on Wikidata. How this damaged Commons? --EugeneZelenko (talk) 14:50, 7 October 2017 (UTC)[reply]

Rollback proposal

I propose that the edits by JarektBot (talk · contribs) which removed geolocation data from Wikimedia Commons categories are reverted, keeping in place the Wikidata location or Q-number and the geolocation data in the template, and consequently readable in the wikitext. This is in compliance with the community norms per Commons:Don't be bold. Rollbacks will look like: 

From: {{Object location|Wikidata=Q3591667}}
To:   {{Object location|44.4528|3.6167|Wikidata=Q3591667}}

Keeping both the Wikidata number and the geolocation data on Commons will ensure backwards and forwards compatibility. If the data needs later fixing (which seems highly unlikely), then a Wikidata poweruser can easily sync the data, if the Wikidata version is considered to be the most reliable version. At the current time, the Wikidata version is no more reliable than the Commons versions they were created from and there is no community consensus that future category data cannot be added or maintained on Commons rather than requiring all Commons contributors to do this on Wikidata.

As Jarekt (talk · contribs) is an administrator, a proposal and community consensus is necessary to avoid any action against non-administrators that may rollback their edits, should Jarekt continue to refuse to do this themselves or recognize that a Wikimedia Commons community consensus is required for the mass removal of geodata. Thanks --Fæ (talk) 14:01, 6 October 2017 (UTC)[reply]

  •  Support as proposer. --Fæ (talk) 14:01, 6 October 2017 (UTC)[reply]
  •  Strong oppose if coordinates are same. --EugeneZelenko (talk) 14:03, 6 October 2017 (UTC)[reply]
    The coordinates are not "the same", as once removed from Commons there will be no way for Commons users to track changes to geodata unless they start adding all related Wikidata records to their global watchlists (which don't exist). --Fæ (talk) 14:05, 6 October 2017 (UTC)[reply]
    There are option to show Wikidata changes for stuff in watchlist. Seems to be enabled by default. --EugeneZelenko (talk) 14:07, 6 October 2017 (UTC)[reply]
    Yes, I see I switched it off as it filled my watchlist full of irrelevant crud, like every time a language got added, which affects me in no way at all. I'm very disappointed to see that a Commons Bureaucrat is arguing against establishing a consensus on Commons for sweeping changes on Commons. --Fæ (talk) 14:29, 6 October 2017 (UTC)[reply]
    Isn't suggesting to developers to add filter by Wikidata properties for watchlist is better solution then creating conflicts in Commons? By the word, if Commons is single repository for media, why you deny same role for Wikidata for data? --EugeneZelenko (talk) 14:37, 6 October 2017 (UTC)[reply]
    @Watchlist: I've marked Wikidata edits with gray (in my CSS on WP) .mw-changeslist-src-mw-wikibase { background: #DDD } -- User: Perhelion 14:45, 6 October 2017 (UTC)[reply]
    For the record, better filter options are coming -- they're currently being tested on el-wiki -- to only show changes in labels/descriptions/statements that are actually used in the tree of templates on the page, rather than any/all changes in Wikidata items they access. This requires bigger database tables behind the scenes, to link pages to relevant statements rather than relevant items; and there are probably still aspects of watchlist flooding it won't solve; but apparently, initial results on el-wiki already look like a substantial improvement. Jheald ( talk) 17:03, 6 October 2017 (UTC)[reply]
    Another quite useful hack is to use the Listeria tool to produce regular wikified snapshots of the results of particular Wikidata queries, used to extract particular subsets of interest. One can then look at the page history to see diffs for eg all changes made in the past month. Jheald (talk) 17:06, 6 October 2017 (UTC)[reply]
  •  Oppose per my comment above. - Offnfopt(talk) 14:23, 6 October 2017 (UTC)[reply]
  •  Oppose that's the sense of Wikidata -- User: Perhelion 14:37, 6 October 2017 (UTC)[reply]
  •  Support Perfectly glad to see us draw from Wikidata, but it's looking like we won't be able to watchlist changes there (too much burden on the servers); I want to see it be possible for a bot to tell if values there drift away from those we have, or this is going to be a big gift to vandals. - Jmabel ! talk 15:25, 6 October 2017 (UTC)[reply]
    Drifted coordinates can be highlighted by template code. Also files with different coordinates can be added to category. Of course, it is better to make WD changes watching user-friendly, but that looks like a miracle after so many years. — Vort (talk) 15:45, 6 October 2017 (UTC)[reply]
Template code already tracks different levels of matches between Wikidata and Commons coordinates, see Category:Pages with coordinates from Wikidata. Pages with large mismatch (> 1km) (or wrong precision set on Wikidata) and up here and pages with moderate mismatch (>20m and <1 km) end up here. Changes to Wikidata do show up on watch pages of people watching siteling pages, or if you add them to you watchlist there. One can also probably write queries for items with locations away from parent administrative territorial entity (P131) and maybe combining it with resent edits. That might be better way to track vandalism. --Jarekt (talk) 16:40, 6 October 2017 (UTC)[reply]
  •  Oppose the final page is exactly the same. The only change it that it does not show up in Category:Pages with local coordinates and matching wikidata coordinates tracking category and it loads a bit faster since the code does not need to compare locations from 2 sources. Only pages with coordinates matching up to 20 meters or in cases of areas (like countries, or large cities) closer than the coordinate "precision" value stored on Wikidata. --Jarekt (talk) 16:40, 6 October 2017 (UTC)[reply]
    @Jarekt: One objection above is that if the local page no longer has a local copy of the values in wikitext, then it can no longer be scraped by existing tools that rely on scraping that wikitext to get the coordinates. That seems quite a significant and important objection to me. Jheald (talk) 16:57, 6 October 2017 (UTC)[reply]
Each page with {{Location}} template has a standard link like https://tools.wmflabs.org/geohack/geohack.php?pagename=File:Hunebed_015.jpg&params=052.951900_N_0006.785500_E_globe:Earth_type:camera_region:NL-DR&language=en , so the standard way to scrape the coordinates is to use Special:LinkSearch and extract coordinates from the URL. Than the coordinates end up in some database used by all the tools. The link remains unchanged, so the scraping should not be affected. --Jarekt (talk) 17:37, 6 October 2017 (UTC)[reply]
  • could we not have 2 locations. the archived custom commons location, and the wikidata location? this would allow visual inspection for those wikidata-phobic. Slowking4 § Sander.v.Ginkel's revenge 17:13, 6 October 2017 (UTC)[reply]
  •  Oppose In view of what Jarekt writes above, that it is easy to scrape the pages. Jheald (talk) 17:52, 6 October 2017 (UTC)[reply]
    You must be joking. Rather than keeping wikitext compatible with past scripts and including the wikidata links you want, you think it is a good idea to force everyone else to rewrite programs and Bots to do webscraping of our own project? That is painfully bad design. You guys have been flogging wikidata for years, but you still only offer hacked make do solutions to breakages you are forcing on others. This discussion is getting much darker than I would ever have expected. --Fæ (talk) 18:15, 6 October 2017 (UTC)[reply]
    @Fæ: I'm open to your expert assessment; and I can see that it might be a good idea to take a time-out to assess what tools might be affected, and whether a simple drop-in fix can be created for them. But if Jarekt is correct, that the links from {{Location}} have always been available in one of the existing SQL tables, and will continue to be so, that sounds a much better way to get the data (particularly at scale, or joined with category information) than scraping pages -- with no need to run multiple approaches on different sites and then combine them. Plus, per the examples I gave above, there will now also be the SPARQL service, which makes the co-ordinate data much more available at scale than it was before, and allows it to be combined with other properties of the item in ways that are more flexible, more precise, and more consistent than category information offers. Jheald (talk) 19:32, 6 October 2017 (UTC)[reply]
I am not aware of any tools that do their own scraping of coordinates from wikitext, or keep their own databases of coordinates. As the coordinates can be input in variety of formats (and on multiple planets), it is much easier to scrape from machine-readable output of the template. I also do no believe any tools are doing scraping themselves, as it is easier to rely on existing databases. For items with Wikidata link it is even easier as you can just write a simple SPARQL query and get locations that way. If someone maintains a tool or script that is affected by this change, I would be interested to learn about it. --Jarekt (talk) 20:20, 6 October 2017 (UTC)[reply]
Had you bothered to get a consensus for your mass changes, you would not be guessing. Revert your deletions and discuss rather than shifting blame. --Fæ (talk) 20:41, 6 October 2017 (UTC)[reply]
@Fæ: It's useful to start from where we are now, rather than making Jarekt make reverts and then re-restores before we discuss, which may be turn out to be unnecessary.
For the benefit of the rest of us to know which way to jump on this, it would useful to have some examples of tools that are scraping this data, and why Jarekt's point about the existing variety of input forms is not a strong one. Jheald (talk) 20:57, 6 October 2017 (UTC)[reply]
BRD. It's very simple and works everywhere else. If Administrators lobbying for wikidata are not able to respect basic norms, there is no chance of working collegiately. You are polarising us into friends and enemies. Revert or there can be no future discussion as there is no possibility of trust. --Fæ (talk) 21:43, 6 October 2017 (UTC)[reply]
@Fæ: The last thing I want to do is to polarise people, or make strong demands on anybody. I just want a calm discussion and to better understand the issues. It seems to me that Jarekt has made a strong point, but you've done so much work in this area, and you don't agree. So I want to understand in more detail why not -- specific case examples would really help, and be very powerful. Jheald (talk) 00:44, 7 October 2017 (UTC)[reply]
  •  Support per se.--Ineedpicslol (talk) 19:14, 6 October 2017 (UTC)[reply]
  •  Oppose wasting time here. Multichill (talk) 20:19, 6 October 2017 (UTC)[reply]
    Consultation, diplomacy, and consensus-building is seldom a waste of time. Jheald (talk) 20:39, 6 October 2017 (UTC)[reply]
    But feeding the drama lama's is a waste of time. Multichill (talk) 21:02, 6 October 2017 (UTC)[reply]
    Speaking of drama lamas, you resigned from Commons in 2015, on this Village Pump. Nice to see you still taking part, though I suggest you ponder the old maxim about glass houses before getting so dismissive of others who are still committed to this project. --Fæ (talk) 21:54, 6 October 2017 (UTC)[reply]
    gosh, i wonder why editors would lose commitment to this project? i wonder where our wikidata overlords learned their abrupt, high handed methods? i wonder why creator template happened without fuss? is it because no one cares about creator metadata, but all the amateur coders hate it, when a better solution comes along that is not backward compatible? as we know the location of a photograph is worth edit warring over. Slowking4 § Sander.v.Ginkel's revenge 21:50, 7 October 2017 (UTC)[reply]
    Try to keep track of the facts before going off on a sarcastic tangent. There is no edit war here, as there has only ever been one party making edits. There is no single "wikidata overlord" that would claim to have learned how to edit Commons from me. As for creator metadata, this project makes a presumption of CC-BY-SA where not specified otherwise, so any metadata where human creativity such as estimated dates or human judgement about geo-location, especially when applied to a large set of items, should not be automatically exported to Wikidata where it gets re-released as CC0, without discussion. By default community consensus is required before significant mass actions such as this can be legitimately rolled out, as there are clearly several complex issues to talk through, some of which fundamentally redefine how Commons will work in the future and may retrospectively apply to several million past uploads. --Fæ (talk) 12:52, 10 October 2017 (UTC)[reply]
    @Fæ: Thank you for highlighting this difference in licensing. I have never licensed my contributions of geocoding info to Commons as CC0, and anyone who misrepresents that I did deserves to be punished.   — Jeff G. ツ 13:58, 11 October 2017 (UTC)[reply]
    i guess we know how the licensing migration people felt Commons:License_Migration_Task_Force#How_do_we_handle_people_who_want_to_opt_out.3F - it's as if they did it again, but without the feedback. thank you for not edit warring. i think we all underestimate our contribution to the toxic culture, and this action is yet another symptom. your "data" is on a US server, do you want to apply European data copyright rules to it? would you seek that punishment in a US court? or do you propose a ban ex post facto? Slowking4 § Sander.v.Ginkel's revenge 15:14, 12 October 2017 (UTC)[reply]
 Support per proposer.   — Jeff G. ツ 21:25, 6 October 2017 (UTC)[reply]
Zoom, Region, etc. was not removed as they are not redundant. --Jarekt (talk) 03:18, 7 October 2017 (UTC)[reply]
 Support per proposer. Keith D (talk) 21:47, 6 October 2017 (UTC)[reply]
  •  Support per proposer. Blue Elf (talk) 22:12, 6 October 2017 (UTC)[reply]
  •  Oppose Thibaut120094 (talk) 06:57, 7 October 2017 (UTC)[reply]
  •  Support: This kind of vandalism would be unacceptable even if Wikidata were stable, reliable, and properly supported by a user community. -- Tuválkin ✉ ✇ 08:42, 7 October 2017 (UTC)[reply]
    @Tuvalkin: Why do you think this is "vandalism" ? Something doesn't become so, just because you use the word. What that is useful is it, that you think Commons is losing in Jarekt's edits ? Jheald (talk) 10:46, 7 October 2017 (UTC)[reply]
    Yes, I do think that Commons is losing in Jarekt’s edits. It’s a large scale removal of very useful information contributed by the Commons community, to be stored off-site in a concurrent project whose history of dealing with Wikimedia Commons have been one of needless antagonism. -- Tuválkin ✉ ✇ 11:02, 7 October 2017 (UTC)[reply]
    Wikidata and Commons are not concurrent projects. Wikidata is doing same for data as Commons for freely licensed media. Data is not removed, it's strored in different place and shared with all WMF projects. Please also read mw:Reading/Multimedia/Structured Data about direction to where Commons is moving. --EugeneZelenko (talk) 14:55, 7 October 2017 (UTC)[reply]
  •  Oppose the use of rollback. The edits made by Jarekt's bot are on a very large scale and so now that they have happened (although clearly without strong consensus), a calm and measured approach would be to begin a discussion and allow it to terminate. Then act again. Reverting is a reckless action for this number of edits. It is not difficult to restore the values if that is what is decided upon. As for the issue of maintaining the data stored in wikitext, I can't see any reason listed by users disagreeing above that explains it is worthwhile to keep doing that. Which currently active tools actually scrape category page wikitext for geocoords? There appears to be only benefits from sharing the coordinate data with other wikis. seb26 (talk) 15:11, 7 October 2017 (UTC)[reply]
  •  Oppose WTF? two wrongs do not make a right. you have to model collaboration, not revert lack of collaboration. otherwise you would have to restore hundreds of thousands of deleted files. we need a wikidata noticeboard / teahouse to ease the transition to structured data on wikidata. and some category; custom template tools are going to break. Slowking4 § Sander.v.Ginkel's revenge 21:56, 7 October 2017 (UTC)[reply]
  •  Support The bot discarded simply geographical location data if they did not match. Consider, for example, this wikidata entry vs. this removal. The least Jarektbot could do is to keep the differing geographical location at Commons in such cases but this did not happen. The watchlist extension as described above does not help in such cases as the entries differed before. As long as the first random location that has been copied to wikidata trumpets over all others without attempting to resolve this, we will have to deal with a potential loss of quality. (It is not a big difference in the example I cited but the original Commons position pointed nicely into the centre of the object.) In general, there is a lot to be said in regard to transfers of data to Wikidata with manifold pros and contras. This needs a more in-depth community discussion which should not be skipped as it happened here. Even if we move this kind of data to wikidata, we need to decide before how exactly we want to do it to avoid any loss of data which has been curated here over years. This is much unlike the Creator templates. This is not about a year of birth etc which are either correct or not but about somewhat fuzzy data which can be improved as the technical means to determine a precise geographic position have been improved over time. Conflicts arise naturally here and should not be resolved by selecting a random variant. --AFBorchert (talk) 16:52, 8 October 2017 (UTC)[reply]
    • This seems to me to be the heart of the matter. Also possibly at issue, it is possible to have more than one geographic location legitimately associated with the same object, and disagreement is not always an indication that either location is wrong. For example, an archeological specimen might appropriately be associated both with where it was originally found and where it currently resides (e.g. in a museum), as well as, imaginably, where it was manufactured. - Jmabel ! talk 19:34, 8 October 2017 (UTC)[reply]
  •  Info The last days I have done some merges on Wikidata mainly for object created twice (once from wikipedia and another time from the sv and ceb bot created articles in geographical context). For the sv and ceb bot generated coordinates the process goes like this:
    1. coordinates are taken from geonames which in the meantime is user generated and maintained content. The quality of these data could be better. In many cases the precision is only minutes, not seconds. Some values are wrong. As geonames is user generated content, general rule applies: it is not reliable enough for Wikipedia
    2. Wikidata imports coordinates from the swedish WP (i.e. geonames) to Wikidata, stating the Swedish WP as the source
    3. Somebody (e.g. commons) uses this coordinates from Wikidata
    4. Even worse, somebody from outside the wikiverse uses these coordinates from Wikidata (at least that is the next big thing we hope to intrude)
    5. If now, in case of differing coordinates on commons, these will be removed in favor to the coordinates found on Wikidata, we get a self-consistent set of identical but probable wrong coordinates.
I'm in favor of keeping single data in single places and not having them redundantly duplicated all over the wikiverse creating conflicts over and over again. But the precondition is that values are quality assured and correct to level still to specify (or are there some Q metrics for every property stating what the guaranteed maximum of wrong data in Wikidata is and are they enforced? - weird idea). If only identical multiple coordinates are removed, should be ok for me. But it is a no-go to remove contradicting values by stripping all but one arbitrary value. best --Herzi Pinki (talk) 13:32, 8 October 2017 (UTC)[reply]
Whatever you think about these discussions, they must be had before changes, so that no individual is given the power to force their opinion that metadata that happens to have been (haphazardly) uploaded to Wikidata must be permanently removed from Wikimedia Commons. It is supreme arrogance for Jarekt to force their ideas on this project and then refuse to revert the changes. In exactly the same way, it is tiresomely political to do mass changes without consensus, and then to argue that "we are where we are" as if the changes cannot be easily reverted. BRD (and simple civility) seems to apply, and be enforced, everywhere but to Wikidata evangelists.
I used to be a general supporter of better use of Wikidata, such as Wiki Loves Paintings, but seeing the defensive circling of wagons and reverse logic plus outright refusal to comply with basic norms of working collegiately, my reserve of good will has been burnt to zero. It'll take a hell of a lot of convincingly good work, demonstrating that Wikimedia Commons is not going to be damaged or made irrelevant, for me to want to lift a finger to support any future Wikidata project. --Fæ (talk) 13:40, 8 October 2017 (UTC)[reply]
Fæ, you have repeated several times now that Jarekt and others supporting the transfer of some data to Wikidata are not "working collegiately". However, you don't appear to have responded to the queries above when it was asked which wikitext scraping tools would be affected if any, nor made any suggestions about how the data currently stored in wikitext could potentially assist other Wikimedia projects, which it can't currently do if stored exclusively on Commons. Furthermore, I don't think it is positive or collegiate at all to continuously characterise other community members using terms like "evangelists" and "lobbyists" when we are supposed to be considered one team with the same interest in mind. It was not a good idea to move ahead with this bot task without discussing it but there is also no need for some kind of mass emergency reversion before more discussion is had. It is difficult to continue in this current discussion when all participants are not permitted the same level of respect. seb26 (talk) 15:01, 8 October 2017 (UTC)[reply]
Complying with BRD is basic. Actively refusing to do is disrespectful. Twisting Jarekt's actions into being my personal problem to solve makes no sense. --Fæ (talk) 15:13, 8 October 2017 (UTC)[reply]
As always in arguments, Fæ's concern for accurately reporting other's statements/beliefs/positions/actions takes second place to making some outrageous point. Fae's statement implies the same individual did "mass changes without consensus" and then argued "we are where we are". As far as I know Jarekt and I are not the same people. It is not "tiresomely political" to argue "we are where we are" -- that is a fundamental of dispassionate consideration of any problem. Fae is solely concerned with how we got here -- not seeking consensus for what he considers a controversial change -- and it does not help his argument at all to listen to the many people who claim that such moves are not only beneficial but the future of Commons. We will eventually not be responsible for recording locations, dates of birth, professions, the listed status of buildings, etc, etc. That belongs to another project. This whole proposal is designed to allow Fae to punish Jarekt and justify the above angry bullying. What everyone is saying, but Fae doesn't want to hear, is that these things need calm rational discussion, with an open mind, and, frankly, the total rejection of views like Tuvalkin's, who seems unable to accept any change to their little world. -- Colin (talk) 20:30, 8 October 2017 (UTC)[reply]
If coordinates are wrong in Wikidata/Commons/Wikipedia, isn't Wikidata is best place to fix a problem and remove wrong copies from other projects? --EugeneZelenko (talk) 14:46, 8 October 2017 (UTC)[reply]
my point (if you refer to my statement above) is that data are wrong in geonames. So to fix this you have to go to geonames and fix coordinates there, reimport it from there and quality assure them on wikidata. (loop here). As I said above, single place is better than multiple places with non-consistent data, but wrong data imported from some external platform is worse. Folding to one wrong value, is creating an alternative fact. So sad! (as a rule of thumb, geocoordinates (at least in developed countries and at least for small objects) should not be disputed in most cases, but could be considered to be correct or incorrect / utterly inaccurate or unknown (= no coordinates in wikidata). There is a mismatch between the force of a bot not caring for special cases and the toil of the community fixing such things one by one. --Herzi Pinki (talk) 16:18, 8 October 2017 (UTC)[reply]
  •  strong oppose Communication before making a big change does seem like a good thing to do. So I think Jarekt should have considered that making such a change might have caused concern among those less enlightened than himself. However we are where we are. This is now effectively a proposal to copy data out of wikidata and pointlessly duplicate it on Commons simply.... well it seems simply to rub Jarekt's face in it and that really just amounts to bullying. I know people hate change, and those who are familiar and comfortable with the old ways hate it the most. But Commons is a media repository, not a general data repository. The location of the subjects of our images, for example, is not Commons' concern. We need reasonable rational discussion about the migration of data to where it belongs, not the sort of pitchforks and fire and bullying we see above from several individuals. -- Colin (talk) 16:28, 8 October 2017 (UTC)[reply]
Colin you are right I should have remembered last time I was helping someone with cleaning up unused attributes parameters from {{Location}} templates, and many of my changes met with a lot of opposition. The fact that the parameters were not used and were causing issues for people parsing them was not important. It seems like {{Location}} templates are much more controversial than other templates. For example, in 2012 I added 60k {{Authority control}} templates to commons categories and last year replaced most of them with a single Wikidata identifier. In the process we have found a LOT of pages with conflicting identifiers and in the most cases Wikidata were the correct ones. I was announcing my plans for changes ahead of time but rarely heard anything back. But {{Location}} templates are different I guess. I just hope that this new interest in location templates translates into more clean up of maintenance categories like Category:Pages with local coordinates and mismatching wikidata coordinates. --Jarekt (talk) 01:58, 9 October 2017 (UTC)[reply]
  •  Oppose except for hurt feelings (that I can relate to, there should have been a discussion before ; but was is done is done, get over it) I don't see any problem with what I thik is an improvement. Cdlt, VIGNERON (talk) 08:27, 11 October 2017 (UTC)[reply]
  •  Oppose Reverting steps towards using Wikidata as central hub for certain information like coordinates of objects makes no sense. As a user that is doing a lot of cleanup tasks i see the lack of people willing to work on metadata of categories and files, repairing templates, cleaning maintenance categories etc. on Commons. Only WD will allow us to be able to manage these challenges by uniting the different communities. So instead of reverting discussions about good steps already taken we should talk about what next should be done to move redundant information to WD. --Arnd (talk) 13:37, 11 October 2017 (UTC)[reply]
  •  Oppose Per VIGNERON: I understand that Jarekt thought these edits were uncontroversial, and it turns out more discussion would have been necessary for this to go more smoothly. I’m sure Jarekt will keep that in mind next time around. That said, I also see this as an improvement, and don’t see the need for reverting. Jean-Fred (talk) 08:17, 12 October 2017 (UTC)[reply]
  •  Oppose Per Slowking4's pointing out that two wrongs don't make a right. This discussion started 10 days ago now. There are apparently no examples of any problems this has actually caused, so I don't see the need for a massive rollback. I agree with Fae that this SHOULD have been discussed in advance, but unfortunately it wasn't, however, I also believe Jarekt did not think it would be controversial. There should be a larger discussion somewhere about this topic when it comes to erasing data from any Wiki sites to centralize it on Wikidata. Wikimandia (talk) 04:41, 15 October 2017 (UTC)[reply]
  •  Oppose. While it would have been courteous to give a heads-up in advance, I strongly support the move of such data to a centralised database for all Wikis, just as Commons is Wikimedia's centralised image repository. As long as the Wikidatafied coordinates on Commons agree with those already present in Wikidata, I see no reason to mass revert. Fæ has yet to come up with actual examples of broken scripts, although I think such scripts are mostly based on the output text rather than the wiki source code. The output text at least has a consistent notation, regardless of the source code that can be written in either decimal or dms notation. --HyperGaruda (talk) 18:18, 21 October 2017 (UTC)[reply]
  •  Oppose 1. I support the need for a prior discussion In Commons (not in Wikidata) for such mass edits. I don't like the comment made by Multichill; such attitude must be stopped. I hope that user remember how I protested when they edit warred on file pages of Archaeodontosaurus. That matter resolved when the user changed the attitude and moved for a healthy discussion. Anyway we've a discussion for this matter now. 2. {{Object location|44.4528|3.6167|Wikidata=Q3591667}} is not a solution as both the coordinates here and in Wikidata can be different when somebody altered the coordinates here (later) which leads to inconsistencies. There is little chances that somebody remove the wikidata property when altering the coordinates here. So this redundant data will end up as misinformation too. Jee 13:21, 22 October 2017 (UTC)[reply]

October 06

Higher resolution upload

Hello. I have started to upload higher resolution copies of files, which are hosted at Flickr. In accordance to creativecommons.org website, hi-res versions have the same licenses as lo-res ones [1] [2] (previous discussion). But Denniss states that it is wrong. What community can say on this topic? — Vort (talk) 12:55, 16 October 2017 (UTC)[reply]

@Vort: Creative Commons follows copyright law (at least in the US per Bridgeman Art Library v. Corel Corp.) on this, and we should too. The work is copyrighted, not the digital representation of it. Under cc-by-sa-2.0, as currently used by File:IvanStewartProtruck.jpg and the Flickr source, this is not an issue. Note that FlickreviewR 2 and FlickreviewR did similar uploads of higher-resolution images from Flickr for years without such concerns. It seems that Denniss's request goes beyond copyright law, may be disregarded, and should be retracted.   — Jeff G. ツ 13:21, 16 October 2017 (UTC)[reply]
@Vort: I also do not understand Denniss'es concerns and agree with User:Jeff G. statement above. I also do not understand how did we got low-resolution image in the first place as most tools would upload full resolution image. --Jarekt (talk) 15:32, 16 October 2017 (UTC)[reply]
@Jeff G. and Jarekt: The copyright applies to the work, but are you saying it is not possible to grant a license on a low-res version of a work without granting a license on the highest resolution that exists? - Jmabel ! talk 15:35, 16 October 2017 (UTC)[reply]
My understanding is that you can not have different licenses for different resolution works when using CC-BY or CC-BY-SA licenses (I am not sure about other licenses), because what is licenses is the work not it's representation. Also In case of Flickr images, and Commons images you have a single page with a license for for it and many links to download it using different resolution. You are not able to set it up to have different license for different resolution. Finally if we were allowed to have different license for different resolutions lets say I freely license image at one resolution and release it under a license incompatible with Commons for a different resolution, than it is unclear what would be the copyright status of images derivative of freely licensed image which were resized to the size of the other one. if someone made low-res to have more restrictive license we might not be able to tell the difference between two copies with two different licenses. --Jarekt (talk) 15:47, 16 October 2017 (UTC)[reply]
At some point Commons:Bundesarchiv after Bundesarchiv uploaded low-res versions of 80k files there was discussion about copyright status of higher resolution of the same photographs. As I recall some early Bundesarchiv templates indicated that CC license only extend to low-res images, but it seems like that language is no longer in Bundesarchiv templates. --Jarekt (talk) 15:58, 16 October 2017 (UTC)[reply]
This has been discussed previously, several times I think. See what Commons:Licensing currently says about it: "Sometimes, authors wish to release a lower quality or lower resolution version of an image or video under a free license, while applying stricter terms to higher quality versions. It is unclear whether such a distinction is legally enforceable, but Commons's policy is to respect the copyright holder's intentions by hosting only the lower quality version." --ghouston (talk) 23:07, 16 October 2017 (UTC)[reply]
That last makes sense to me.
@Jarekt: So would you also say that the license I issued for File:Georgetown Rainier malt house interior 01 - blurred.jpg inherently covers the original photo without the Gaussian blur? Or do you feel there is a difference between reduced resolution for the whole work & a Gaussian blur over part of it? Or what? (Mostly just wondering.) Because at some point it seems to me this would have to reach a point of absurdity. If I produced a 4x4 color field, based on the color distribution in a photo I took, surely I could license the 4x4 color field without that providing a license on a legible version of the photo. - Jmabel ! talk 02:27, 17 October 2017 (UTC)[reply]
It's sad that Commons allows people to use it as advertisement platform. But since this point is specified in rules, I will check licenses. Maybe I will make a report about bot failures (including dissimilar licenses) later. — Vort (talk) 05:40, 17 October 2017 (UTC)[reply]
Jeff/Vort, I think Denniss is being reasonably cautious. Remember that uploading anything to Commons is done at your own risk, and if a creator has tagged an image as "(c) All rights reserved" on Flickr, with no-longer any CC licence and you upload it here, then I think you are being legally foolish. This is just a hobby, nobody pays you, nobody employs you, and nobody has your back if you get into trouble. The only sensible thing is to upload images that are clearly free, and since we are a repository of free images, the only sensible and responsible thing to do wrt anyone re-using the works we host, is to only offer works that are clearly free. I think in this case, that is not clearly so, as the creator has clearly signalled their intentions to not offer the high-resolution work for free. Note: you may think the files are identical other than in resolution, but may have in fact undergone further post-processing that may or may not be sufficient to make it a new work-of-copyright.
Wrt licensing, of course it is possible to licence only a digital copy of a work -- publishers do that every time you buy music or a film -- it doesn't give you any rights to the master copy and if you buy a DVD you have no rights to get the Blu-Ray for free. Creative Commons consider the "scope" of their licence to be the "work of copyright" rather than a particularly copy/instance. Most of the world doesn't appreciate that distinction, and this was historically made worse by WMF/CC misleading creators in older literature on the topic. It is also a problem that Flickr does not warn users the consequences of choosing CC nor the consequences of changing the licence tag.
Jmabel, I think the answer to your question is whether your edits have produced a new/separate derivative "work of copyright". This seems to vary by country and ultimately up to a judge to decide. As noted, the MediaWiki software is capable of producing images of varied size, varied crop and even a little sharpening, all automatically and all not generating new works of copyright. The answer to a lot of copyright questions seems to be "nobody knows" because the question is specific to each case, not many such cases have reached the courts, and even if they did, a court ruling in the US may not help someone in the UK come to a decision. -- Colin (talk) 08:33, 17 October 2017 (UTC)[reply]
I have found an interesting service: imagestamper.com, which can help to solve similar problem in the future. Also, upload bot can make a copy of page from image hosting, which contains copyright information, with one of internet archives. — Vort (talk) 10:17, 17 October 2017 (UTC)[reply]
"creator has clearly signalled their intentions to not offer the high-resolution work for free" — it is possible that hi-res version was available also at the time when it was uploaded to Commons. — Vort (talk) 11:21, 17 October 2017 (UTC)[reply]
"you may think the files are identical other than in resolution, but may have in fact undergone further post-processing that may or may not be sufficient to make it a new work-of-copyright" — if my algorithm not seeing any difference, then human eye all the more. — Vort (talk) 11:23, 17 October 2017 (UTC)[reply]
"if a creator has tagged an image as "(c) All rights reserved" on Flickr": Commons should have a strong protection against such actions. Allowing to fool yourself is a bad thing. — Vort (talk) 11:30, 17 October 2017 (UTC)[reply]
Flickr images uploaded by bots and other tools always had the highest available resolution uploaded. Our review process verified the license at time of upload, eiher automatic by bot or a little later by human reviewer. --Denniss (talk) 12:19, 17 October 2017 (UTC)[reply]
"had the highest available resolution": It looks unbelievable that ~5% of Flickr users reuploaded hi-res versions. — Vort (talk) 12:22, 17 October 2017 (UTC)[reply]
Here is the proof: File:Upper Provo River Utah.jpg have this link at Flickr: https://www.flickr.com/photos/11513086@N00/395263622 . 395263622 is photo id, which can be pasted to API request: ht​tps://api.flickr.com/services/rest/?method=flickr.photos.getInfo&api_key=my_key&photo_id=395263622, which will give result:
Request result
<?xml version="1.0" encoding="utf-8" ?>
<rsp stat="ok">
  <photo id="395263622" secret="39fd4ca55b" server="176" farm="1" dateuploaded="1171887754" isfavorite="0" license="4" safety_level="0" rotation="0" originalsecret="39fd4ca55b" originalformat="jpg" views="79" media="photo">
    <owner nsid="11513086@N00" username="outkast9821" realname="" location="" iconserver="249" iconfarm="1" path_alias="" />
    <title>Upper Provo River</title>
    <description />
    <visibility ispublic="1" isfriend="0" isfamily="0" />
    <dates posted="1171887754" taken="2007-02-19 04:22:34" takengranularity="0" takenunknown="0" lastupdate="1176350976" />
    <editability cancomment="0" canaddmeta="0" />
    <publiceditability cancomment="1" canaddmeta="0" />
    <usage candownload="1" canblog="0" canprint="0" canshare="1" />
    <comments>0</comments>
    <notes />
    <people haspeople="0" />
    <tags />
    <urls>
      <url type="photopage">https://www.flickr.com/photos/11513086@N00/395263622/</url>
    </urls>
  </photo>
</rsp>
1171887754 is 2007-02-19, 1176350976 is 2007-04-12. File is uploaded to Commons 2009-01-24, it was not touched since 2007 at Flickr. But uploaded resolution was 1024 × 768 instead of original 1600 × 1200. — Vort (talk) 12:37, 17 October 2017 (UTC)[reply]
Vort, I don't know what you mean by "Commons should have a strong protection against such actions. Allowing to fool yourself is a bad thing." Protection for what purpose? Protection so we can steal photos that the creator explicitly chooses not to be free? Protection so we can take advantage of some random amateur photographer who doesn't understand a complex licence issue that only a lawyer could grasp and that even WMF/CC didn't understand? What sort of Commons is that? You are getting photos for free, for no effort. If you can't respect the image creator, then bluntly I don't think we need folk like you on Commons, and your actions are not per policy. Perhaps I misunderstand your position, but you don't seem to be listening. Wrt the other matters.. It could be older Flickr upload software did not always capture the highest resolution version, though I can't figure out why it wouldn't. Note that "ImageStamper" has been in "early beta" since it was created in 2008. I wouldn't advise trusting it. -- Colin (talk) 13:16, 17 October 2017 (UTC)[reply]
"Protection for what purpose?" — so the user can trust "CC-BY" mark and know that irrevocability is not an empty word. "so we can take advantage of some random amateur" — otherwise "amateur" will have an ability to hunt down regular users (example). That is more dangerous than loss of some rights because of inattention. "If you can't respect the image creator" — changing of irrevocable license is more disrespecting than reluctance to fix someone's mistakes. — Vort (talk) 13:57, 17 October 2017 (UTC)[reply]
Sorry bis this comment indicates lack or disrespect auf authors and their authority to issue or deny free licenses for certain works + the Precautionary principle we are oblieged to at Commons. I suggest @Krd: immediately blocks your Bot until the issue is solved. --Denniss (talk) 14:21, 17 October 2017 (UTC)[reply]
I'd suggest Vort stops the bot job until issues have been discussed. Sometimes it appears that objections arise after the bot request was closed, and it's always a good idea to start slowly when there is no need to hurry. As alternative one could suggest to modify the code to at first process files only that are available in the higher resolution under the same license. --Krd 14:54, 17 October 2017 (UTC)[reply]
Krd: Since morning the bot is reuploading only CC-BY, CC-BY-SA, CC0 and PD images. — Vort (talk) 15:18, 17 October 2017 (UTC)[reply]
Vort, the perpetual offer by the creator was for the image they uploaded to Flicker when they applied the tag. I agree that is perpetual and why we have flickr review to record in case they change their mind. People are always entitled to withdraw the offer of licensing an image, so changing the tag on Flickr is not a wrong thing to do. If the user later uploads a larger image version but associates no free licence, then no you have no Community consensus to upload that, nor do you have any legal advice from WMF/CC saying you can do that either. They did not offer legal advice last time and nor would they in future. It is a legally grey area, and it is ethically unjustifiable. This has been discussed at length, several times, and policy is clear. -- Colin (talk) 15:05, 17 October 2017 (UTC)[reply]

 Kommentar A higher resolution file is in my opinion not the same image as a lower resolution file due to losses during the compression. If a photographer has made a lower resolution file available for CC-BY but not the higher resolution image, then that should be honoured. For me it is similar to a photographer publishing two versions of the same image but edited (photoshopped etc.) in a different way. - Takeaway (talk) 14:51, 17 October 2017 (UTC)[reply]

 Kommentar Let me propose to separate the discussion on two different scenarios: in both cases we uploaded in the past low-res image from flickr using CC-BY or CC-BY-SA license and at the present moment find that there is a larger image available. If the license DID NOT change than new upload of high-res image should not be controversial. If the license DID change (which should be rare) than lets look at those cases individually. Maybe Vort's bot should check if the current license on Flickr match License on Commons and skip the file if it is not, while saving it's name so we can look at it latter. I think the above discussion focused on some hypothetical rare case, and it is hard to judge it without seeing some examples. --Jarekt (talk) 12:28, 18 October 2017 (UTC)[reply]

Jarekt: Here is the list of hires files, skipped by the bot for now: User:Vort/FlickrReuploadReport. — Vort (talk) 16:23, 18 October 2017 (UTC)[reply]
Vort, I looked at them and it seems to me that the photographer changed the license on flickr. I believe you have right to reupload file again to get it at the full size; however since the photographer changed their mind about the license, I would not be doing any more downloads of it. We value flickr community of photographers and the last thing we want to do is to antagonize them. Hopefully that is a small percentage of the files that can be improved. I would add {{Flickr-change-of-license}} to those files and leave them alone. I can add that template if you want once you are all done. By the way, I think this task is very valuable and I am glad someone is doing it. Thanks. --Jarekt (talk) 19:55, 18 October 2017 (UTC)[reply]
@Jarekt: Main part of bot's work is finished. I have updated the report. But I'm not sure if it can be used in automatic way: for example, this list contains "No Known Copyright Restrictions" files, and looks like such files are legal on Commons (did not replaced them because I was not not sure about their status). — Vort (talk) 14:52, 21 October 2017 (UTC)[reply]
The more important part of the report, I think, is images, which failed pixel-by pixel check. Maybe they are better (less cropped version), or maybe not. Top of the list are 100% different, bottom — most likely suitable for reupload, but it is better to check. — Vort (talk) 14:52, 21 October 2017 (UTC)[reply]
Also, I can share database of my bot, if someone is interested in it. — Vort (talk) 14:52, 21 October 2017 (UTC)[reply]
I am looking through your your report where there was license mismatch: there seems like there are 2 cases there:
  • files which originally had CC-BY-2.0 or CC-BY-SA-2.0 but the license was changed on Flickr. I added {{Flickr-change-of-license}} to them and I would not touch them further.
  • Files that are mow under some PD or "No Known Copyright Restrictions" license on Commons, see the list at User:Jarekt/a. Those I think are a fair game to reupload.
All files that I looked at that failed pixel-by pixel check were cases of cropping or color correction on Commons. Those would have to be handled manually, as I can not think of what a bot could do there. One semi-automatic approach would be to download Commons and Flickr images to the computer and compare them visually one by one. Than pick some for reupload, some for crop and reupload. --Jarekt (talk) 13:44, 23 October 2017 (UTC)[reply]
@Jarekt: I have reuploaded /a-files. — Vort (talk) 15:01, 23 October 2017 (UTC)[reply]
There also one more cause for pixel mismatch: incorrect EXIF orientation. Initially, they was just failing pixel test, later I have moved them to specific category. I can share it if needed. — Vort (talk) 15:01, 23 October 2017 (UTC)[reply]
I have all mismatched files downloaded. Can share them with someone, but don't know how. Also, filenames are ids, so id-to-name mapping is needed. — Vort (talk) 15:01, 23 October 2017 (UTC)[reply]

"White Americans"

Category:White Americans seems very problematic to me. I had never noticed it until today when someone added it to a couple of photos I'd uploaded.

The main reason it seems problematic is that unlike, say, Serbian ancestry or sub-Saharan African ancestry, "whiteness" is a very contentious concept. The contentiousness can easily be seen by the fact that subcats include Category:Arab Americans‎, Category:Central Asian diaspora in the United States‎, Category:European Americans‎, Category:Genetic studies on European American‎ (shouldn't that just be a subcat of Category:European Americans‎?), Category:Middle Eastern diaspora in the United States‎, Category:North African diaspora in the United States‎. With the possible exception of European Americans‎, considerable numbers of members of these groups would neither consider themselves white nor be considered so by others.

But also: what purpose does this category serve, and are we really ready to face the consequences of using it consistently? Are we really going to put this on every photo or category of a phenotypically "white" American for whom we don't know a more specific ancsetry? - Jmabel ! talk 19:33, 19 October 2017 (UTC)[reply]

I would delete that category. Indeed problematic and I don't see it as useful. Gestumblindi (talk) 22:07, 19 October 2017 (UTC)[reply]
It's apparently a topic with a long an complicated history in the US. There's a White Americans Wikipedia article, and apparently the United States Census Bureau still uses the term. --ghouston (talk) 02:01, 20 October 2017 (UTC)[reply]
The U.S. Census requires overt identification, typically by the individual but at least by a member of the household. Identifying (for example) all Arab Americans as "white" is a very different matter; so is looking at a photo and deciding the person is "white". - Jmabel ! talk 02:36, 20 October 2017 (UTC)[reply]
I would delete it, too. In the past, under Jim Crow laws in the South (Southern Continental US), only "White Americans" were allowed to vote or own property, in continuation from the enslavement of African Americans for some 400 years. The term is used to fuel white supremacist bigotry, and it has no place in our categorization system.   — Jeff G. ツ 03:09, 20 October 2017 (UTC)[reply]
Actually, legally-sanctioned slavery existed in British North America / the United States for about 225 years, not 400... AnonMoos (talk) 16:18, 20 October 2017 (UTC)[reply]
If we are going to eliminate the category completely, there is quite a bit of work to do. Also, because removal of a category is hard to reverse, I'd want to make sure there was a pretty solid consensus for that. That would also presumably mean removing Category:White Americans in California‎, Category:White Americans in Maryland‎, Category:White Americans in Washington, D.C.‎, and Category:White Americans in West Virginia‎, right? - Jmabel ! talk 15:30, 20 October 2017 (UTC)[reply]
I proposed redirecting the category to another existing one which is not contested, so I'm not sure what you're referring to. But for the sake of the argument, how would that differ from the situation with Category:African Americans? How do you determine an image should belong in that category? FunkMonk (talk) 20:57, 20 October 2017 (UTC)[reply]
In general, I've used Category:African Americans only when either (1) it has already been used by an archive describing that image (E.g. I upload a lot of images from the Seattle Municipal Archives, and they've been known to use it in the description or tags), (2) I know that the individual in question has that self-identification (e.g. in some self-description or official bio/CV), or (3) I have it at the level of citability I'd need for WP (e.g. newspaper articles, etc. referring to them that way). Pretty much the same standard I'd use for any other ethnicity (e.g. Irish American, Serbian American). I agree that "African American" is also a bit problematic, but (I think) less so.
Again, what brought me here was having someone slap the category on a photo presumably based on nothing but appearance + the fact that the photo was in the U.S.
And, for the record, I'd have no problem with redirecting to Category:European Americans, which would also then presumably mean simply removing it from (for example) Category:Arab Americans. - Jmabel ! talk 23:19, 20 October 2017 (UTC)[reply]

The above content has been copied to the CfD at Commons:Categories_for_discussion/2017/10/Category:White_Americans, let's continue there rather that here. - Jmabel ! talk 23:28, 20 October 2017 (UTC)[reply]

Proposal: completely eliminate "White Americans" categories

Proposal: completely eliminate Category:White Americans, Category:White Americans in California‎, Category:White Americans in Maryland‎, Category:White Americans in Washington, D.C.‎, and Category:White Americans in West Virginia‎. Rationale is explained above. In some cases, one or more of the parent categories may need to be used as a substitute. - Jmabel ! talk 15:30, 20 October 2017 (UTC)[reply]

The above content has been copied to the CfD at Commons:Categories_for_discussion/2017/10/Category:White_Americans, let's continue there rather that here. - Jmabel ! talk 23:28, 20 October 2017 (UTC)[reply]

Cfd

A cfd has been started at Commons:Categories for discussion/2017/10/Category:White Americans

peopleByName

Has anyone else noticed that the template {{PeopleByName}} displays the Wikidata link twice? Look at Category:Pancho_Barnes. Is there anyway that it can be displayed just once? The first time displayed is in the upper box when you rollover of the wikidata image with the cursor. The second time is in the box below it. Can we just combine them, or eliminate the second lower box all together. If it isn't obvious that the link is to wikidata is the wikidata emblem, then lets spell it out like in the bottom box but combined into the first box.— Preceding unsigned comment added by Richard Arthur Norton (1958- ) (talk • contribs) 23:20, 19 October 2017‎ (UTC)[reply]

I do not see an issue here. The second box is added by {{On Wikidata}}, and this could be removed from the template, but I find this explicite mention better then the hidden one in the first box, added by {{Authority control}}. — Speravir – 22:56, 20 October 2017 (UTC)[reply]
Why not make the one in the first box visible, instead of the jarring effect of two boxes of different design fused together.— Preceding unsigned comment added by Richard Arthur Norton (1958- ) (talk • contribs) 01:09, 21 October 2017 (UTC)[reply]
  • Signing your posts on talk pages is required and it is a Commons guideline to sign your posts on deletion requests, undeletion requests, and noticeboards. To do so, simply add four tildes (~~~~) at the end of your comments. Your user name or IP address (if you are not logged in) and a timestamp will then automatically be added when you save your comment. Signing your comments helps people to find out who said something and provides them with a link to your user/talk page (for further discussion). Thank you.   — Jeff G. ツ 01:58, 21 October 2017 (UTC)[reply]

October 20

Chimney extentions

Do we have a category for chimney extentions or pipes?Smiley.toerist (talk) 09:11, 20 October 2017 (UTC)[reply]

Think these days they would be termed as w:Flue extensions. No cat that I can find but if you can find three examples or more, then a new cat is probably in order. I don't like creating cats just for the sake of it but toss the idea around to see if it catches on. After all, we may pass many every day without releasing what they are. P.S. I thought that all the chimneys in Holland had storks nesting upon them or is this a another delusion shattered? P.g.champion (talk) 15:06, 20 October 2017 (UTC)[reply]
@P.g.champion: description says these chimneys are located in Paris ;) --HyperGaruda (talk) 18:38, 21 October 2017 (UTC)[reply]

Recently there was a change that replaces in some the full list of links (headed «In Wikipedia») with just a few of them ending with a button that reads "nn more". I need to know how this can be disabled in my preferences. -- Tuválkin ✉ ✇ 20:29, 20 October 2017 (UTC)[reply]

See Special:Preferences#mw-prefsection-rendering. Ruslik (talk) 20:50, 20 October 2017 (UTC)[reply]
Thank you, so much! (Hiding away language diversity as a nuisance, while on the other hand pumping up typeface size, now that’s ne more nail on the coffin of Wikimedia projects as we loved them, by the way.) -- Tuválkin ✉ ✇ 05:23, 22 October 2017 (UTC)[reply]
Why was this change considered desirable? It's not like there is any lack of screen real estate at the bottom of the left column. - Jmabel ! talk 15:52, 22 October 2017 (UTC)[reply]
@Jmabel: I guess some people didn't want to see links to languages they can't read. Analogs of this page are on 222 Wikipedias.   — Jeff G. ツ 16:07, 22 October 2017 (UTC)[reply]

October 21

Just curiousity

I'm locating many pictures (many hundreds to few thousands) and I wonder how many of all Commons files are located (either camera location or item location). Any idea of where to find statistics on that? Thanks. B25es (talk) 07:40, 21 October 2017 (UTC)[reply]

October 22

Need Someone to make a campaign streamer

So I need someone to make a campaign streamer for the Medal for Humane Action. It is seen in this document at the top of page 4: https://www.supplyroom.com/uploads/catalogs/Streamer%20Sets_AF.pdf, and I am looking for a file that is similar to . I have no artistic ability or talent, so any help I could get would be greatly appreciated. Even if you don't have time or the knowledge please direct me to someone who may have this ability. Garuda28 (talk) 00:43, 22 October 2017 (UTC)[reply]

Do you mean "Berlin Airlift 1948-1949"? Ruslik (talk) 19:21, 22 October 2017 (UTC)[reply]

Werkwoorden

Hi, any Dutch speaking admin hanging around? My question: this kind of errors I would like to remove... Would there by oppose? Thank you for your time.:) Lotje (talk) 01:08, 22 October 2017 (UTC)[reply]

@Lotje: while it should be spelled "treedt", the passage seems to be a quotation and we normally do not edit quotations even if they are wrong. If possible, check the reference accompanying the quotation to see if it was really written incorrectly or if it was just an error on the uploader's side. --HyperGaruda (talk) 06:16, 22 October 2017 (UTC)[reply]
According to the article's online scan, the spelling mistake was already in the original. In other words, leave the quotation as it is, or place [''sic''] (displayed as [sic]) after the error if it is really necessary. --HyperGaruda (talk) 06:47, 22 October 2017 (UTC)[reply]
Thank you HyperGaruda, especially for for retracing the scanned link on docplayer.nl, showing the spelling mistake was already in the original. :) Lotje (talk) 11:35, 22 October 2017 (UTC)[reply]

October 23

Flickr members?

Hey all--I was trying to leave a note for a Flickr member, but I can't log in via Yahoo. The image I was going to ask them to change or upload to Commons is this, https://www.flickr.com/photos/27485954@N07/4941423968/in/photolist-7ryBXo-8wE6hm-8wE6mw-8wE6bY-8wE62s-59wiYM . I'm sure lots of you all are active there--can someone please ask this user? (They have another image of the same machine). We really need this at the en-wiki article Portastudio: the 144 is the mother of them all. Thanks! Drmies (talk) 15:32, 23 October 2017 (UTC)[reply]

Tech News: 2017-43

Latest tech news from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. Translations are available.

Recent changes

  • You can use ccnorm_contains_any when you create an abuse filter. This can be used to look for multiple words or phrases within a string. It will find words where some characters have been replaced. You can read more in the documentation. [4]

Changes later this week

  • When you search in some languages the search function could use specific other languages if the first language didn't work. This is called a fallback language. This didn't work properly and created bad searches. The search index is being fixed to work better. [5]
  • The new version of MediaWiki will be on test wikis and MediaWiki.org from 24 October. It will be on non-Wikipedia wikis and some Wikipedias from 25 October. It will be on all wikis from 26 October (calendar).

Meetings

  • You can join the next meeting with the Editing team. During the meeting, you can tell developers which bugs you think are the most important. The meeting will be on 24 October at 18:30 (UTC). See how to join.
  • You can join the technical advice meeting on IRC. During the meeting, volunteer developers can ask for advice. The meeting will be on 25 October at 15:00 (UTC). See how to join.

Future changes

Tech news prepared by Tech News writers and posted by bot • Contribute • Translate • Get help • Give feedback • Subscribe or unsubscribe.

18:18, 23 October 2017 (UTC)

Large lag with categories

Tracked in Phabricator
Task T178840

I've noticed that Commons appears to be currently experiencing a large lag with Category propagation. Anyone else seeing this? —RP88 (talk) 20:28, 23 October 2017 (UTC)[reply]

Possibly related, the Commons job queue has ~5.6 million entries (see [7]). —RP88 (talk) 20:33, 23 October 2017 (UTC)[reply]
@RP88: Yes. This appears to be why Category:Images from the Geograph British Isles project still has 1,653,715 files in it after 16 days.   — Jeff G. ツ 23:10, 23 October 2017 (UTC)[reply]
I wonder if it has something to do with 5M transclusions of Module:Wikidata label, which I was just fixing per phabricator:T173194. But maybe it is a coincidence. --Jarekt (talk) 20:32, 24 October 2017 (UTC)[reply]
Perhaps... but if Jeff's > 16 day estimate above is accurate, the timing doesn't work out since your first attempt at a fix for T173194 was 10 days ago. Given that the Commons job queue has actually grown to ~5.8 million entries, rather than decreased, something else must also be involved since even if your edit was the trigger I"d expect the queue to shrink as the jobs were processed. —RP88 (talk) 02:06, 25 October 2017 (UTC)[reply]

October 24

I do not believe the Wikimedia Foundation has a resolution that as a consequence stops WMF funding going to organizations that appear to choose to claim copyright over public domain materials, or may routinely use first publication rights, or sweat of the brow, to claim commercial rights over old works that would otherwise be presumed public domain. It's central to the Wikimedia Commons project to ensure that projects that produce any type of media, such as scans of old photographs, should produce results which can be released to support all Wikimedia projects that wish to use them. In the current set up, it's often taken as a given for smaller WMF grants, but this is not necessarily implemented under the way that larger funding works, such secondary grants via Chapter funding. I would be interested in putting together a RFC or requesting a resolution along these lines, unless something similar already exists.

Any thoughts on having a community RFC to make this a tangible implementation of WMF declared values? Thanks --Fæ (talk) 15:44, 24 October 2017 (UTC)[reply]

What specific organizations do you mean? Ruslik (talk) 20:15, 24 October 2017 (UTC)[reply]
I support the sentiment, but is it a problem? Does WMF or it's chapters have a history of funding for organisations with a history of copyright misuse? --Jarekt (talk) 20:37, 24 October 2017 (UTC)[reply]
So does this mean we would not work with a museum that happily gives out pretty good scans of their collection, but keeps even higher-res scans internally? - Jmabel ! talk 23:00, 24 October 2017 (UTC)[reply]
@Jarekt: The RFC would be a principle, so it's less helpful to be taken on a tangent about past projects. It is a real problem if proposals to fund paid positions such as Wikimedians in Residence are never asked the question. Funding may well be judged suitable against this principle if the point of having something like a WIR project is to stop copyright misuse within an organization by at the same time adopting better policies.
@Jmabel: Yes, when copyright is falsely misused. Commons does routinely host usable lower-resolution files for the public benefit when the high-resolution versions are not available for free, which is acceptable, though this remains justifiably controversial when the source is misusing copyright by claiming they own creative rights over public domain material. That is entirely different from using WMF charitable donations and funding projects within an organization that at the same time as taking funding, chooses to make profit from selling public domain photographs under demonstrably false copyright claims. Hopefully the WMF, and any chapter, would never consider funding a project within an organization which has this track record, or be seen to partner with them, unless the project is about changing their policies. The intention of the RFC is to ensure this becomes a hard and measurable requirement on funding proposals, which then will flow down via affiliate funding, rather than something we vaguely think is the case and hope will remain the case. --Fæ (talk) 09:59, 25 October 2017 (UTC)[reply]
  • I think it is important that the work produced as a result of WMF funding is properly free. WMF should get value for money so if they are funding the production of images then I'd expect to get high-resolution images with proper free licences suitable for photographic works. If they only get low-resolution images, for example, or if the licence used is not really a free one, then that's not a good use of funding imo. In the past, I have seen WM Austria funding photo production (workshops/equipment) that resulted in images with "GFDL 2.0 Only" licences. This is really not in the spirit of our free movement, as the photographer deliberately chooses that licence option to make the photo legally unusable outside of Wikipedia. Another photographer got a grant (I think from Swiss WM IIRC) for camera equipment and again used the GFDL licence and uploaded only low-resolution images so they could sell the high resolution images to stock photo sites.
  • But in terms of blacklisting whole organisations because of past or current sins, I don't think that is a workable or helpful approach. Who says what scope the definition of "organisation" is? The bad copyright behaviour could be the consequence of one or two individuals, of one department's policy, or of policy in one country, and also could be the result of ignorance that may be resolved by working with WMF. I repeat the other requests for examples of where this has occurred. If it hasn't occurred then it is really hard to get overly concerned about it. -- Colin (talk) 10:31, 25 October 2017 (UTC)[reply]
  • I certainly agree that we should be concerned what is done with images etc. that result from our grant, but I'm less sure that we should boycott organizations because of what they've done otherwise. - Jmabel ! talk 14:56, 25 October 2017 (UTC)[reply]

October 25

Well, this is frustrating

File:Binondo,Manilajf0200 20.JPG is the best photo we have of Chinese New Year in the Philippines but it's just part of a mass upload of someone's personal vacation photos. The pic is noticeably off actual horizontal. I spent the morning finding an online rotation service and getting the photo fixed, then cropped correctly. I uploaded the corrected version, the change is logged, the file size changed, and the pic looks exactly the same. Same wrong borders, same wrong alignment.

I tried purging. No change.

I tried rechecking that the file was actually changed. Wikicommons claims it was and has the new file size listed.

I tried uploading the corrected pic again and the uploader claimed that my version of the photo is the current one. It even displayed the correct version in the thumbnail. Then I click back to the image and, nope, it's still exactly the same as before.

There's no reason to keep the badly-taken form of the photo and have the correct version in a different place. Do I seriously need to move it, delete the redirect, and upload the corrected photo in its place? or does it now take several hours for uploaded photos to display correctly? or what? — Mr Spear (talk) 04:08, 25 October 2017 (UTC)[reply]

Update: Well, I tried using the photo on the Simple Wikipedia and it looks fine on the page. It just still doesn't display correctly here. Weird, but at least the main problem (what people see on the other sites) is fixed. — Mr Spear (talk) 04:17, 25 October 2017 (UTC)[reply]

It looks fine to me. It's presumably a caching issue, either in your browser cache or some other cache between you and the server. --ghouston (talk) 04:22, 25 October 2017 (UTC)[reply]
Mr Spear I'm also seeing the new version, I'm guessing your browser is caching the old image. It varies depending on the browser you use but try Ctrl+F5 or ⇧ Shift+F5 and see if that changes it (see Bypass your cache for other possible key combinations). I also wanted to note that Commons has a Graphic Lab, you can make these type of rotation requests in the Photography workshop section. - Offnfopt(talk) 04:51, 25 October 2017 (UTC)[reply]
Mr Spear, for this cases we have the User:SteinsplitterBot/Rotatebot and a gadget for using it. Clicking on the help" box on the linked page everything is explained. Regards, --Emha (talk) 08:15, 25 October 2017 (UTC)[reply]
  • @Mr Spear: Instead of dealing with an online rotation service, I think it's a lot easier to put GIMP on your machine, download the full-res image, rotate it and/or make any other changes you want, and re-upload - Jmabel ! talk 15:02, 25 October 2017 (UTC)[reply]
cacheing is a perennial issue. some one should change upload new version to include hard purge and hourglass, because it is bad UX design to confuse editors with old versions. Slowking4 § Sander.v.Ginkel's revenge 16:57, 25 October 2017 (UTC)[reply]
Yes, it all looks fine now so sorry for the bother and thank you all for your time and suggestions. Good luck with avoiding similar problems going forward =). — Mr Spear (talk) 23:03, 25 October 2017 (UTC)[reply]
Checkmark This section is resolved and can be archived. If you disagree, replace this template with your comment. --Emha (talk) 07:22, 26 October 2017 (UTC)

Does batch uploading still happen?

I don't mind standing in a queue if it is getting serviced, but I don't want to just line up with no hope of anything ever changing. Can anyone confirm that the batch upload requests at Commons:Flickr batch uploading and Commons:Batch uploading do get served eventually?

Is there anything that people like me can do to help (more than manually download thousands of images then manually upload and document them)? Only two of the seven participants in the Flickr upload page have more than 2 edits in the last six months, and they aren't from bulk uploads. The general page does a bit better, but only 4-6 out of 9 scripters (including one in both lists).

Thank you to the people who do that work and who manage the Commons in support of many Wikipedia and other projects. --Scott (talk) 06:12, 25 October 2017 (UTC)[reply]

Hi, I was asking myself the same question. We clearly need more people with bot/scripting abilities. Regards, Yann (talk) 10:19, 25 October 2017 (UTC)[reply]
yeah, the trust issues with batch uploading, and failure to train a team to curate batch uploading, means that activity will slow to a crawl, when interested parties leave. people have moved on to commons:pattypan and Flickr-to-Commons. Slowking4 § Sander.v.Ginkel's revenge 20:50, 25 October 2017 (UTC)[reply]
Thanks. I had another go with Flickr2Commons, and most of the files I wanted came across and have been approved by FlickreviewR 2 bot. --Scott (talk) 02:04, 27 October 2017 (UTC)[reply]

Adding 500px.com to Commons:Upload by URL

Tracked in Phabricator
Task T178961

Hi. For those of you who are not familiar with the website, 500px is the new cool place for photographers to show off their work. They have support for CC license (on the desktop site and in the API), so they are pretty much on par with Flickr on that. You can check out how a CC-BY-SA image looks here. Getting the image URL is simple: just right-click on the "Download photo" button and select "Copy link" from the menu. This is not possible for non-free images.

Since many of the photographers I follow have moved from Flickr to 500px, I tried to upload some pictures from there and found that none of the tools we currently use have support 500px. As a first step, I logged phab:T178961 to have it enabled on Commons:Upload by URL for trusted users to use. If you know of any images or series of images you'd like to upload from 500px.com, please comment in the bug to gauge how useful that feature would be for other users. Thanks--Strainu (talk) 10:24, 25 October 2017 (UTC)[reply]

Do you have any thoughts about related DRs as per search oder Category:500px.com related deletion requests. It may be worth populating the latter category with missed DRs. --Fæ (talk) 10:41, 25 October 2017 (UTC)[reply]
I prefer to look at the beautiful pictures already uploaded from 500px. :) People will upload copyvios as long as Commons will exist and the number of DRs is insignificant compared to the equivalent number for Flickr. Also, Upload by URL is only available to trusted users (Image reviewers, Admins, GWToolset users) so copyvios will very likely not be an issue if enabled.--Strainu (talk) 11:08, 25 October 2017 (UTC)[reply]
With a bit of thought, it should be possible for someone to work out the ratio of bad/good unique Flickr accounts and compare that with the same ratio from 500px. Perhaps there's a verifiable reason to expect 500px to be better than Flickr? I have no strong view, but if it is statistically worse for license laundering, then I'd be against making mass upload easier. --Fæ (talk) 11:15, 25 October 2017 (UTC)[reply]

Structured Commons newsletter, October 25, 2017

Welcome to the newsletter for Structured Data on Wikimedia Commons! You can update your subscription to the newsletter. Do inform others who you think will want to be involved in the project!

Community updates
Things to do / input and feedback requests
Presentations / Press / Events
Audience at Structured Commons design discussion, Wikimania 2017
Team updates
The Structured Commons team at Wikimania 2017

Two new people have been hired for the Structured Data on Commons team. We are now complete! :-)

  • Ramsey Isler is the new Product Manager of the Multimedia team.
  • Pamela Drouin was hired as User Interface Designer. She works at the Multimedia team as well, and her work will focus on the Structured Commons project.
Partners and allies
  • We are still welcoming (more) staff from GLAMs (Galleries, Libraries, Archives and Museums) to become part of our long-term focus group (phabricator task T174134). You will be kept in the loop of the project, and receive regular small surveys and requests for feedback. Get in touch with Sandra if you're interested - your input in helping to shape this project is highly valued!
Forschung

Design research is ongoing.

  • Jonathan Morgan and Niharika Ved have held interviews with various GLAM staff about their batch upload workflows and will finish and report on these in this quarter. (phabricator task T159495)
  • At this moment, there is also an online survey for GLAM staff, Wikimedians in Residence, and GLAM volunteers who upload media collections to Wikimedia Commons. The results will be used to understand how we can improve this experience. (phabricator task T175188)
  • Upcoming: interviews with Wikimedia volunteers who curate media on Commons (including tool developers), talking about activities and workflows. (phabricator task T175185)
Development

In Autumn 2017, the Structured Commons development team works on the following major tasks (see also the quarterly goals for the team):

  • Getting Multi-Content Revisions sufficiently ready, so that the Multimedia and Search Platform teams can start using it to test and prototype things.
  • Determine metrics and metrics baseline for Commons (phabricator task T174519).
  • The multimedia team at WMF is gaining expertise in Wikibase, and unblocking further development for Structured Commons, by completing the MediaInfo extension for Wikibase.
Stay up to date!

Warmly, your community liaison, SandraF (WMF) (talk)

Message sent by MediaWiki message delivery - 14:27, 25 October 2017 (UTC)[reply]

Tuválkin Structured Commons is going to be Wikidata like storage for data stored currently on file description pages. Instead of text with information about author, date, license, etc. You will have properties of file items. Hopefully the output to the users will not change much, but the underlying storage will. Structured Commons will reside on Commons, instead of Wikidata site.--Jarekt (talk) 15:37, 27 October 2017 (UTC)[reply]

Category help

If someone could move most of the files in Category:Population pyramids of Poland to a subcategory "regions of" or something similar that would be helpful. Ideally they would be moved into a category for each province, but that would be very time consuming. Right now there are 3,418 files in the category, making it almost impossible to find any specific file. For now just move everything that starts with "Piramida wieku". Delphi234 (talk) 22:43, 25 October 2017 (UTC)[reply]

October 26

Federal Government Says an Image is Creative Commons

If a federal government website says that they are using an image that is under a Creative Commons license, do we need any further verification that the license by the photographer is valid? I ask because of this image.Anythingyouwant (talk) 05:50, 26 October 2017 (UTC)[reply]

Alboraia

Alboraia will be Wiki Taken on November 12th. More information can be obtained here and here.

Come and enjoy the real Horta!

B25es (talk) 17:29, 26 October 2017 (UTC)[reply]

Project Grant proposal for Lingua Libre

Lingua Libre's logo
One pronounciation file in the Atikamekw language recorded with Lingua Libre, see Category:Sounds of Lingua Libre for more examples.

Hi!

Lingua Libre is an open source platform created to ease mass recording of word pronounciations into clean, well cut and well normalized audio files. Given a clean words list, a contributor can reach a high productivity level without requiring any technical skills.

It's currently supported by a team of (mostly French) volunteers. Even if the core recording tool is fully functional and very efficient, it currently suffers from a very poor integration with the Wikimedia projects, and first of all Commons. We want to setup an OAuth process, allowing contributors to easily upload (with good-looking descriptions and the appropriate categories) the pronunciation files with their own account.

To accelerate the development of this tool and overcome this problem (and many others), we have submitted a Project Grant proposal. If you're interested by this project, take a look at the proposal, on meta: ⇒ meta:Grants:Project/0x010C/LinguaLibre.

Ping @~riley and CoolCanuck: who are part of the WikiProject Pronunciation.

Thanks for your comments — 0x010C ~talk~ 20:18, 26 October 2017 (UTC)[reply]

I support this project. I already uploaded some files I recorded through Lingua Libre there Category:Atikamekw pronunciation and my first comment was "There is no tool to upload the files to Commons from the Lingua Libre interface?" It is very time consuming the way it is right now, but Lingua Libre is very well done for the recording part. The improvements proposed by User:0x010C will be most welcomed. Thank you, Amqui (talk) 21:37, 26 October 2017 (UTC)[reply]

Connecting...

Tracked in Phabricator
Task T179122

When I click on "Good pictures", it often says "Connecting..." (which takes forever). Is this a common problem, and how do I fix it? Thanks ~ DanielTom (talk) 21:49, 26 October 2017 (UTC)[reply]

@DanielTom: You are not alone. I got the same result on Category:Mycalesis junonia, which contains the POTD. I have reported it in phab:T179122.   — Jeff G. ツ 21:59, 26 October 2017 (UTC)[reply]

October 27

Image donation (2140 photos)

A new image donation has been uploaded recently: Commons:Wilhelm_Walther_image_donation/en. While the motifs are mostly locations across Germany during the 30s, there are some photos of a ship trip to a landscape that might be Norway (?). Moreover, there is a lot of everyday motifs from early and mid-1930 Germany that might be of interest for you. Your help with categorizing and annotation would be appreciated – have fun! --Elya (talk) 09:13, 27 October 2017 (UTC) PS: and maybe a native speaker would be so kind and improve my english translation of the project page, thx![reply]

Thank you. This is marvellous! I've had a quick run through the English project page cleaning up the translation and learning a few new German words along the way. --bjh21 (talk) 10:33, 27 October 2017 (UTC)[reply]
Thank you very much, I love this community! (most of the time ;-). --Elya (talk) 10:54, 27 October 2017 (UTC)[reply]
Agreed on all accounts! (Hurrying to check whether there’s tram photos in this set…) -- Tuválkin ✉ ✇ 14:59, 27 October 2017 (UTC)[reply]

Turning off categories

How does one turn off categories on a page, such as Help:Flickr review templates? It is displaying all of the templates for Flickr reviews, but it should not be placed into those templates respective categories. --Elisfkc (talk) 14:12, 27 October 2017 (UTC)[reply]

Hello @Elisfkc and Jarekt: , every of this templates should have a category parameter. You can see the usage for example here: COM:T -- User: Perhelion 14:16, 27 October 2017 (UTC)[reply]
@Perhelion: I am not sure what you mean. I am trying to eliminate the page, Help:Flickr review templates, from being categorized, while the templates continue to categorize elsewhere. --Elisfkc (talk) 14:22, 27 October 2017 (UTC)[reply]
I do not think there is a category parameter with those templates, but I will fix it. --Jarekt (talk) 14:25, 27 October 2017 (UTC)[reply]
@Jarekt: Every single one of those categories images normally (the page is in 15 categories at the moment, when it shouldn't be in any of them). --Elisfkc (talk) 14:29, 27 October 2017 (UTC)[reply]
I will restrict those categories to files only. --Jarekt (talk) 14:30, 27 October 2017 (UTC)[reply]
Yes, use Template:iffile, e.q. for Template:Flickr-unfree-but. -- User: Perhelion 14:46, 27 October 2017 (UTC)[reply]
Fixed Wow those were some old templates that needed fixing. I guess nobody looked at them before, by creating page like Help:Flickr review templates. --Jarekt (talk) 15:00, 27 October 2017 (UTC)[reply]
👍 -- User: Perhelion 16:41, 27 October 2017 (UTC)[reply]

RFC: Which user groups should initially be allowed to upload mp3s?

Now that mp3s are no longer patent-encumbered, and WMF Legal has signed off on allowing mp3s on our projects, we need to decide how mp3 uploading will actually be implemented. There appears to be general consensus to enable mp3 uploading, but many people have expressed concerns about the potential for increases in copyvio uploads. A solution that has been proposed would be to limit mp3 uploads to particular user groups. Should we limit it to particular groups, and if so, which groups? Note that we already disallow all uploads of large audio files by newbie users through edit filters. Kaldari (talk) 22:22, 27 October 2017 (UTC)[reply]

Note 'user groups' here refers to Commons:User access levels#User groups, not Category:Wikimedia user groups. ;-) --John Vandenberg (chat) 02:24, 28 October 2017 (UTC)[reply]

Limit to admins and higher

A special permission level

  • Create a special permission level that has to be explicitly requested by non-admins. Make it easy to ask for, and grant it readily to experienced users, but I think auto-confirmed is too low a bar. - Jmabel ! talk 22:57, 27 October 2017 (UTC)[reply]
  • The phased approach mentioned in the previous RFC would imply a "MP3 uploaders" group is created. That seemed to be the consensus of the last RFC. John Vandenberg (chat) 02:31, 28 October 2017 (UTC)[reply]
  • Maybe we need a new level of general "Uploaders" that could be trusted to upload MP3 files, upload directly from flickr using UploadWizard, have higher upload limit in UploadWizard, etc. A position of trust, which can be granted by the community, and removed if person is abusing those powers. --Jarekt (talk) 02:37, 28 October 2017 (UTC)[reply]

Limit to auto-confirmed and higher

Don't limit by user group

Discussion

I'm quite confused about your RFC. It doesn't seem to me to accurately reflect the complexity of the previous discussions. The previous discussion mentioned a new user right, not user groups. If this is just a terminology issue, and you are talking about a new user right, why can't it be held by multiple existing user groups or even a new group? Where did the three options come from? Why just these three? Is your RFC intended as a replacement for the phased approach suggested by CKoerner (WMF)? It is not clear to me whether you are suggesting that this user group restriction, if any, is about the "Phase 0" testing phase that precedes the "everybody can upload MP3" phase that occurs after the tool intended to assist with patrolling MP3 uploads is developed. Or are you proposing some sort of indefinite restriction on mp3 uploads to particular user groups? —RP88 (talk) 23:11, 27 October 2017 (UTC)[reply]

If this RFC is about which user groups should be granted the "upload mp3" right during the "Phase 0" testing phase mentioned in the previous discussion, personally I think this hypothetical uploadmp3 user right should be held by "Image reviewers", "Administrators" and a new group "MP3 uploaders" that would be easy to acquire at COM:RFR and readily revoked if abused. After the tools are ready I think MP3 should be treated like other file types and the uploadmp3 right would then be added to all of the existing groups that currently have the upload right. —RP88 (talk) 23:25, 27 October 2017 (UTC)[reply]

October 28

Retrieved from "https://commons.wikimedia.org/w/index.php?title=Commons:Village_pump&oldid=264847581"