Open main menu

Wikimedia Commons β

Commons:Village pump

Shortcut: COM:VP

Community portal
introduction
Help desk Village pump
copyrightproposals
Administrators' noticeboard
vandalismuser problemsblocks and protections
↓ Skip to table of contents ↓       ↓ Skip to discussions ↓       ↓ Skip to the last discussion ↓
Welcome to the Village pump

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

Please note


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

Purposes which do not meet the scope of this page


Search archives


 

Village pump in Rzeszów, Poland [add]
Centralized discussion
See also: Village pump/Proposals • Archive

Template: View • Discuss  • Edit • Watch


August 31Edit

Glam project - Derivative works of Picasso worksEdit

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

Read-only Commons in preparation for 3D file support - 11 OctoberEdit

The Multimedia team at the foundation is getting closer to enabling support for uploading and displaying 3D models on Commons. We have to do some work on the database to get ready for 3D file support. This means we'll need to put Commons in read-only mode for about 30 minutes on Wednesday October, 11th at 6:00 UTC. [1]

You will be able to read, but not edit Commons for a short period of time.

  • You will not be able to edit or upload media for approximately 30 minutes on Wednesday, 11 October, starting at 6:00 UTC (07:00 BST, 08:00 CEST, 02:00 EDT, 23:00 PDT).
  • If you try to edit or save during these times, you will see an error message. We hope that no edits will be lost during these minutes, but we can't guarantee it. If you see the error message, then please wait until everything is back to normal. Then you should be able to save your edit. But, we recommend that you make a copy of your changes first, just in case.

Why?

The team needs to modify the database primary master so it understands this new file type. This will then allow for the future ability to upload and display 3D models on Commons (and embed in other Wikimedia projects). Want a sneak-peek? Take a look at this programmatically created crystal on Test Wikipedia. It is important to note that the ability to upload 3D files will not be available immediately after the maintenance ends (but at a later date), this only involves the contributor-impacting database work.

How can folks monitor?

You can keep track of the changes by joining #wikimedia-tech (connect)

Where do I go with issues?

If you have issues after the database work is completed, please report a ticket on the Wikimedia Bug tracker http://phabricator.wikimedia.org

Please help share this with your community.

Yours, CKoerner (WMF) (talk) 20:52, 4 October 2017 (UTC)

Will support for .m4a and .mp4 be added as well? Before I was blocked, I was trying to upload a .mp4/.m4a audio file for a welcome message on Wikipedia to make it more accessible. Plus, people with broken displays will be able to still use Wikipedia. I know screen readers can already read the text, but on Edge, Narrator has trouble reading the text. Ups and Downs () 05:34, 11 October 2017 (UTC)
No - We already have "support" for that, so no downtime would be needed for them to be enabled. However those formats are disabled for political reasons. See Commons:Requests_for_comment/MP4_Video for background. Bawolff (talk) 18:41, 11 October 2017 (UTC)

Input requested on 3D object file upload processEdit

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)

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. -- (talk) 10:04, 5 October 2017 (UTC)
@CKoerner (WMF): I +1 Fæ. :) --Steinsplitter (talk) 13:32, 5 October 2017 (UTC)
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)
+1, and very well put. - Jmabel ! talk 20:01, 5 October 2017 (UTC)
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. -- (talk) 20:11, 5 October 2017 (UTC)
"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)
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)
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)

October 05Edit

Object location data being hijacked away to WikidataEdit

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)

┌─────────────────────────────────┘
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? -- (talk) 15:01, 5 October 2017 (UTC)

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)
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... -- (talk) 15:12, 5 October 2017 (UTC)
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)
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 -- (talk) 15:29, 5 October 2017 (UTC)
"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)
@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)
(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)
@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). -- (talk) 16:09, 5 October 2017 (UTC)
Pictogram voting comment.svg Comment 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)
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. -- (talk) 16:02, 5 October 2017 (UTC)
@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. @: What has already broken (or is about to break) from your POV?   — Jeff G. ツ 16:09, 5 October 2017 (UTC)
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. -- (talk) 16:26, 5 October 2017 (UTC)
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)
Also, the same list, now sorted by distance: tinyurl.com/y77hhn9v Jheald (talk) 18:24, 5 October 2017 (UTC)
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)
@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. -- (talk) 19:11, 5 October 2017 (UTC)
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)
Good job Jarek. Keep up the good work. Multichill (talk) 20:24, 5 October 2017 (UTC)
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)
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)

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

┌─────────────────────────────────┘
Sorry for dropping the subjet here then apparently disappear (even forgot to sign!). All points I could have made are being made by , 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)

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)

Rollback proposalEdit

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 -- (talk) 14:01, 6 October 2017 (UTC)

  • Symbol support vote.svg Support as proposer. -- (talk) 14:01, 6 October 2017 (UTC)
  • Symbol oppose vote oversat.svg Strong oppose if coordinates are same. --EugeneZelenko (talk) 14:03, 6 October 2017 (UTC)
    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). -- (talk) 14:05, 6 October 2017 (UTC)
    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)
    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. -- (talk) 14:29, 6 October 2017 (UTC)
    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)
    @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)
    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)
    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)
  • Symbol oppose vote.svg Oppose per my comment above. - Offnfopt(talk) 14:23, 6 October 2017 (UTC)
  • Symbol oppose vote.svg Oppose that's the sense of Wikidata -- User: Perhelion 14:37, 6 October 2017 (UTC)
  • Yes, it seems that’s true. Which is one more reason to oppose. -- Tuválkin 11:06, 7 October 2017 (UTC)
  • Symbol support vote.svg 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)
    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)
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)
  • Symbol oppose vote.svg 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)
    @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)
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)
  • 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)
  • Symbol oppose vote.svg Oppose In view of what Jarekt writes above, that it is easy to scrape the pages. Jheald (talk) 17:52, 6 October 2017 (UTC)
    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. -- (talk) 18:15, 6 October 2017 (UTC)
    @: 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)
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)
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. -- (talk) 20:41, 6 October 2017 (UTC)
@: 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)
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. -- (talk) 21:43, 6 October 2017 (UTC)
@: 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)
  • Symbol support vote.svg Support per se.--Ineedpicslol (talk) 19:14, 6 October 2017 (UTC)
  • Symbol oppose vote.svg Oppose wasting time here. Multichill (talk) 20:19, 6 October 2017 (UTC)
    Consultation, diplomacy, and consensus-building is seldom a waste of time. Jheald (talk) 20:39, 6 October 2017 (UTC)
    But feeding the drama lama's is a waste of time. Multichill (talk) 21:02, 6 October 2017 (UTC)
    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. -- (talk) 21:54, 6 October 2017 (UTC)
    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)
    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. -- (talk) 12:52, 10 October 2017 (UTC)
    @: 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)
    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)
Symbol support vote.svg Support per proposer.   — Jeff G. ツ 21:25, 6 October 2017 (UTC)
  • Symbol support vote.svg Support for coordinates where additional data (zoom level, region, etc) has been lost; otherwise Symbol oppose vote.svg Oppose. Once these additional parameter values can be held in or derived from Wikidata, remove them here. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 21:28, 6 October 2017 (UTC)
Zoom, Region, etc. was not removed as they are not redundant. --Jarekt (talk) 03:18, 7 October 2017 (UTC)
Symbol support vote.svg Support per proposer. Keith D (talk) 21:47, 6 October 2017 (UTC)
  • Symbol support vote.svg Support per proposer. Blue Elf (talk) 22:12, 6 October 2017 (UTC)
  • Symbol oppose vote.svg Oppose Thibaut120094 (talk) 06:57, 7 October 2017 (UTC)
  • Symbol support vote.svg 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)
    @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)
    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)
    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)
  • Symbol oppose vote.svg 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)
  • Symbol oppose vote.svg OpposeSymbol wtf vote.svg 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)
  • Symbol support vote.svg 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)
    • 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)
  • Pictogram voting info.svg 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)
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. -- (talk) 13:40, 8 October 2017 (UTC)
, 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)
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. -- (talk) 15:13, 8 October 2017 (UTC)
As always in arguments, '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)
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)
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)
  • Symbol oppose vote.svg 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)
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)
  • Symbol oppose vote.svg 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)
  • Symbol oppose vote.svg 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)
  • Symbol oppose vote.svg 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)
  • Symbol oppose vote.svg 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)

October 06Edit

Double doors and bridging floor sectionsEdit

Düsseldorf H-Bahn 2017 8.jpg
and File:Düsseldorf H-Bahn 2017 3.jpg. We dont seem to have a category for double doors (vehicle and platform). There is Category:Platform screen doors. By the H-Bahn it is even more complicated as there is bridging floor wich drops down to cover the gap between the platform and the vehicle. As the suspended vehicle has some freedom of movement, it pushes against the vehicle to have a tight fit. How are these things called?Smiley.toerist (talk) 12:13, 9 October 2017 (UTC)
I think the usual English phrase for the bridging floor is "gap filler". --bjh21 (talk) 21:57, 9 October 2017 (UTC)
Tangentially, American rail operators have not adopted the British "MIND THE GAP" terminology.   — Jeff G. ツ 13:39, 11 October 2017 (UTC)

Userboxes about place of originEdit

Hi there! I was trying to add userboxes in my userpage and it seems the "Users from Israel" is broken, only works the ""user live in Israel" and I dont live there. Its here the rigth place? Sorry and thanks of advance. ゴスロリ (talk) 17:47, 9 October 2017 (UTC)

  • The issue is in Template:User Israel. Its wording is not parallel to (for example) Template:User United States or Template:User Egypt. It looks like this has been true since the creation of the template 7 years ago, so I hesitate to edit and fix it, given that it's part of a set of templates I've never worked on. @Geagea: you created this, do you see any reason it shouldn't parallel these other templates? - Jmabel ! talk 19:57, 9 October 2017 (UTC)

Loading map data on other websitesEdit

Is it possible to dynamically load map data from Commons on other websites? I can’t figure out how to get past the CORS restrictions – as far as I understand, this (using jQuery and ES6 syntax) should work, but doesn’t:

$.getJSON(
  'https://commons.wikimedia.org/w/index.php',
  {
    title: 'Data:Copenhagen_Districts.map',
    action: 'raw',
    origin: '*' // anonymous request
  },
  data => console.log( data )
);

Firefox just says “CORS header ‘Access-Control-Allow-Origin’ missing”. --Lucas Werkmeister (talk) 11:26, 10 October 2017 (UTC)

Apparently index.php doesn’t support CORS at all, only api.php does… this is ugly, but works:
$.getJSON(
  'https://commons.wikimedia.org/w/api.php',
  {
    format: 'json',
    action: 'query',
    titles: 'Data:Copenhagen_Districts.map',
    prop: 'revisions',
    rvprop: 'content',
    origin: '*'
  }
).then( function( response ) {
  var pageId, content;
  for ( pageId in response.query.pages ) {                                                                                                                                    
    content = response.query.pages[ pageId ].revisions[ 0 ][ '*' ];
    return JSON.parse( content ).data;                                                                                                                                      
  }
} ).done( data => console.log( data ) );
--Lucas Werkmeister (talk) 15:22, 10 October 2017 (UTC)
Feature request at phab:T177966. --Lucas Werkmeister (talk) 17:35, 11 October 2017 (UTC)

Please correct the copyright statement. The map is not CC-zero, it is CC BY-SA per your source. As such, derived works from it, such as data subsets, should not be exported to Wikidata or any other website without respecting the license. -- (talk) 18:26, 11 October 2017 (UTC)

all Data: namespace is CC-zero, it rolled out only allowing CC-zero contributions. Where are you seeing a CC BY-SA notice? - Offnfopt(talk) 19:16, 11 October 2017 (UTC)
I attempted to raise this up for a deletion request but I'm getting errors just doing that.
DR nomination: Data media must be verifiably CC0. The data source for this map is under ODbL, see https://www.openstreetmap.org/copyright, which requires attribution and so is not reusable in a CC0 derived work.
If I get time, I'll try again later or raise a Phab ticket.
... Phab:T178051 Unwriteable error when creating DR in Commons:Data now raised, as this is likely to be a generic issue. -- (talk) 09:29, 12 October 2017 (UTC)
Where did you see the notice of OSM data use in the first place in regards to Data:Copenhagen_Districts.map? The source never stated OSM. It does have a invalid source listed that needs to be corrected, but it never stated OSM data as a source. - Offnfopt(talk) 15:44, 12 October 2017 (UTC)
The indication was that the displayed image page states "Map data (c) OpenStreetMap", which if untrue should be removed because any passing user would read that as "map data" in the actual data file, and the CC0 statement must be qualified to explain that the image displayed is not CC0, it's confusing for casual re-users who may snapshot the image thinking that attribution is not needed. As for the rest, that's a discussion for the DR. It's not convincing that someone made up political boundary lines one day, they must have based the data on a official published map or derived data source. -- (talk) 15:53, 12 October 2017 (UTC)
@: Sorry, but I have no idea what you’re talking about. What copyright statement do you mean, and what’s “my source” supposed to be? I just picked Data:Copenhagen Districts.map as an example to demonstrate my problem, I didn’t upload it and don’t have anything to do with it. --Lucas Werkmeister (talk) 10:36, 12 October 2017 (UTC)
Yes, the comments relate to the uploaded file, rather than your use of it. -- (talk) 11:10, 12 October 2017 (UTC)
Alright, thanks for the clarification :) --Lucas Werkmeister (talk) 12:05, 12 October 2017 (UTC)

┌─────────────────────────────────┘
Anyone interested in the issue of CC0 of Data namespace and the use of OSM data may find Commons:Deletion requests/Data talk:Kuala Lumpur Districts.map worth visiting. Thanks -- (talk) 11:10, 12 October 2017 (UTC)

October 11Edit

Library of Congress - PD vs "no known copyright restrictions"Edit

Hey all, {{PD-Gottlieb}} correctly notes that "the photographs in this collection entered into the public domain on February 16, 2010"—but the line above it gives the usual LOC "no known copyright restrictions" line, even though those words don't appear in the linked LOC page. Is there a way to modify the template to hide that sentence in this instance? Thanks! Ed [talk] [majestic titan] 02:23, 11 October 2017 (UTC)

I don't think the template is misleading as it currently stands. When the LoC says "No known restrictions" they are essentially saying "we think this item is PD, but it may a derivative work of a work still protected by copyright, or protected by other rights (privacy, publicity, etc.)." Depending on how or which database you retrieve these items from at LoC, some of the items in the collection might show just the shorter "No known restrictions" phrasing (for example, https://www.loc.gov/item/2010634561/ ). —RP88 (talk) 03:06, 11 October 2017 (UTC)
"derisive" => "derivative" - Jmabel ! talk 03:21, 11 October 2017 (UTC)
Yes, it was an autocorrect error that I've now fixed. Thanks for the nudge. —RP88 (talk) 04:08, 11 October 2017 (UTC)
feel free to discuss on template talk. i do not see the conflict. and there is the caveat: "but rights of privacy and publicity may apply" you are not going to get an iron clad "PD hold harmless" from any institution. either / or thinking is naive. Slowking4 § Sander.v.Ginkel's revenge 02:23, 12 October 2017 (UTC)
That's true for all images uploaded here, public domain or not... Ed [talk] [majestic titan] 01:06, 13 October 2017 (UTC)
yes, but could incorporate in the license template since it applies to this collection. Slowking4 § Sander.v.Ginkel's revenge 11:37, 16 October 2017 (UTC)
@The ed17: I modified it in English for you in this edit, perhaps we need a new internationalized template.   — Jeff G. ツ 05:03, 12 October 2017 (UTC)
Thanks, Jeff G. Ed [talk] [majestic titan] 01:06, 13 October 2017 (UTC)

Visual Editor everywhereEdit

Hi folks, seems that the simple source editor does not exist anymore. Now i see the VE but with source code inside. What has happend. Several tiny tools do not work anymore now. --Arnd (talk) 12:45, 11 October 2017 (UTC)

@Aschroet: You may have different results on different wikis. Exactly where are you seeing this issue?   — Jeff G. ツ 13:31, 11 October 2017 (UTC)
Jeff G., i had VE (resp. all beta features) enabled. Both edit links led to VE. Then i turned off the VE in my preferences. Now i have only one "Edit" link. But still, i end up in VE showing me the source code (like now when typing this comment). I do no experience that on dewiki. --Arnd (talk) 14:00, 11 October 2017 (UTC)
@Aschroet: It sounds like you've got the visual editor's source mode beta feature enabled, yes. Go here, and ensure that both "New wikitext mode" and "Automatically enable all new beta features" are unchecked to disable it. I'm sure the team would love your feedback if you have any thoughts about it. Jdforrester (WMF) (talk) 15:50, 11 October 2017 (UTC)
Jdforrester, you were right. Thank you, --Arnd (talk) 07:00, 12 October 2017 (UTC)
I really hope the VE will not replace the "native" edit-mode!? Otherwise this solution will only be at times!? -- User: Perhelion 09:04, 12 October 2017 (UTC)

October 12Edit

Extended read-only of CommonsEdit

Since 6:30 UK time to now, that's 4 hours, I have (mostly) been unable to upload files to Commons using the API. Is there a known operational outage or a Phab ticket? In the meantime I raised Phab:T178051 based on trying to create a DR, which may have the same root cause or be coincidence.

FYI the API error returned is:
readonly: The wiki is currently in read-only mode. [readonlyreason:The database has been automatically locked while the replica database servers catch up to the master.; help:See https://commons.wikimedia.org/w/api.php for API usage. Subscribe to the mediawiki-api-announce mailing list at <https://lists.wikimedia.org/mailman/listinfo/mediawiki-api-announce> for notice of API deprecations and breaking changes.]

I have no idea why the error was inconsistent, but most attempted uploads were being rejected. I've stopped attempting uploads for the time being as mostly skipping uploads is actually worse for my projects to repair afterwards than no uploads. -- (talk) 10:08, 12 October 2017 (UTC)

@: I've seen database locked, read-only, try again later messages while just trying to post to discussion pages or do the occasional CropTool crop upload during that time (about 3% of attempted edits), so it's not just you or just the API.   — Jeff G. ツ 10:25, 12 October 2017 (UTC)
The difference may be that for one of my projects where I've seen 100% errors, the upload image are around 20MB to 200MB. This means the uploads take 10 minutes plus each. That 10min+ window of connecting to the API is presumably long enough to always see a read-only outage. I treat that as effective down-time for Commons, and should be reported by operations. If there's a serious "brown-out" issue on the project for several hours, it would be nice to read an analysis about it, and recommendations on how it can be avoided. I don't really want to build in yet more error traps that see very large files endlessly reattempted on an upload loop when I'm already using chunked uploading.
Just to clarify, this was not happening yesterday or in the past week for files from the same collection. So it's not "normal". -- (talk) 10:32, 12 October 2017 (UTC)
+1, i asked on #wikimedia-operations duing the outage but got no reply. --Steinsplitter (talk) 10:37, 12 October 2017 (UTC)
That bug is unrelated. The error message is caused by the db servers detecting they are overloaded (there is an automatic cut off to go into read only mode during an overload (Im simplifying slave lag too high to mean overload). Currently all the wikidata recentchanges rows are being deleted (to fix watchlists - phab:T177772), naively i might guess that the deletion script was a little too aggressive, but thats just a guess (Edit: this guess was incorrect. See bug). (Re Fae's error trap question - api has a maxlag url parameter for this purpose) Bawolff (talk) 14:27, 12 October 2017 (UTC)
Damn, I'm going to have to build a bigger boat. Looking back through my historic OS map uploads, I see that the missing files are probably not missing from the source, but were skipped after failed upload attempts. For example the Cornwall jigsaw has lots of missing pieces. Doubling down on this error for large files is the fact that when I run an existence check there is an unmeasurable potential period of waiting for indexing (minutes, longer?) between having successfully uploaded a file and it being visible through the API by doing an "existence" check; in effect that's why I do not rely on that method. It's a nasty hole to patch.
If you know of something that does these sorts of API based or Pywikibot based checks, I'd appreciate a link. Thanks -- (talk) 16:15, 12 October 2017 (UTC)
For the delay in existence check - I assume we're referring to asyncrounous chunked upload where the chunks are recombined in a background job? Getting the success of that is kind of hard. If you don't specify the async option then the file is recombined immediately (synchrounous mode), and there is no arbitrary delay - although that makes uploads much more likely to fail. In async mode, I think you can use the ?action=upload&filekey=YOUR_STATUSKEY&checkstatus=true in order to check the status of the upload, so you can distinguish between upload is pending but not yet on commons from upload has failed and you should try again.. Bawolff (talk) 17:39, 12 October 2017 (UTC)
@: 20MB in 10+ minutes translates to average upload throughput of 267 or less kilobits per second (kbps). That's about 9x as fast as my 28.8 kbps modem could have done over dialup 20 years ago, but it's only about 1/18 as fast as the cablemodem here can do today over WiFi (capped at 5 Mbps up because the local cable monopoly can get away with that). Never mind the bigger boat, you could use a bigger pipe.   — Jeff G. ツ 04:54, 14 October 2017 (UTC)
Fae: To clarify a misconception, in regards to "That 10min+ window of connecting to the API is presumably long enough to always see a read-only outage" - I believe thats wrong. AFAICT, the lag is only checked once the upload is finished, and processing of the file is handed off to php, so its a relatively short window during which the read only mode is checked. However, the api has stricter lag checks than the main site (Main site will go into read only mode if slave lag exceeds 6 seconds. The API will go into read only mode if slave lag exceeds 3 seconds (unless maxlag parameter is set to something stricter). The idea being, if something is being overloaded, we should try to stop the bots first before stopping real users). In any case, this issue seems to have stopped at about 10:30 UTC. I did file a bug though phab:T178094. Bawolff (talk) 17:39, 12 October 2017 (UTC)

So to summarize what appears to have happened. At October 12 07:18 UTC a script was started to delete all the linter warnings about misnested html tags on all wikis (phab:T178040). It appears to have finished with commons at about 10:25 UTC. This script contained code to check to make sure it wasn't overloading servers - every 500 deleted entries it would check slave lag. However that was not often enough, so what would happen is it would briefly overload the db, wait for the db to fix itself, and then overload the db again. This caused the intermittent read-only error ([https://grafana.wikimedia.org/dashboard/db/mysql-replication-lag?panelId=4&fullscreen&orgId=1&from=1507789800000&to=1507806000000&var-dc=eqiad%20prometheus%2Fops pretty graph. Any time the value of all the servers (other than dbstore) is > 6 a read only error happened. Any time more than half the servers are > 3 the api went read only). From what I've been told, this went unnoticed because it didn't trigger any alerts - the alerts only get triggered if the lag stays for a while. Since the lag bounced up and down very quickly, it was never persistent long enough to trigger an alert. My impression from the bug is that ops is looking into adjusting how the alerts work to make sure that such things are alerted for in the future. Bawolff (talk) 01:37, 13 October 2017 (UTC)

Genuine thanks for the analysis, it's been an interesting thread on phabricator. It's something I'll fiddle with in a statemachine way in my Pywikibot workarounds to see if I can avoid the hammer of looping batch uploads. -- (talk) 12:30, 13 October 2017 (UTC)

Looking for the name of this manEdit

Who is it ?

Hello, from french Wikipédia, I ask here, spécialy to the danish people. The man on this picture have the Order of the Dannebrog (necklace with "W"). And the french Légion d'honneur. Picture made by Nadar around 1880/1900 I think. - I have looking in the danish Category [2] no sucessfully. I think some people can have an idea or contact a place in danish Wikipedia because I have not found their Bistro (Village Pump). You can see also here, a french research zone on that problem : [3] Thanks at all. - Siren-Com (talk) 13:09, 12 October 2017 (UTC)

w:Ferdinand Julian Egeberg ?? w:Félix de Muelenaere ?? a little late for w:Rolf Andvord ?? Slowking4 § Sander.v.Ginkel's revenge 15:27, 12 October 2017 (UTC)
here is a query [4] Slowking4 § Sander.v.Ginkel's revenge 16:11, 12 October 2017 (UTC)
Great thanks... I will use this item regulary ! - Siren-Com (talk) 09:01, 13 October 2017 (UTC)
The Village Pump of Danish Wikipedia is situated at da:Wikipedia:Landsbybrønden. I have made a question there for you. --Dannebrog Spy (talk) 15:06, 14 October 2017 (UTC)
What about da:Carl Meldahl wikidata = Q12305316 as sugested by Brams on da:Wikipedia:Landsbybrønden. --Villy Fink Isaksen (talk) 19:29, 14 October 2017 (UTC)

October 13Edit

Technical error with Wikimedia audio playerEdit

I noticed a technical error with the default player embedded within Wikimedia projects, as I was playing the audio File:De-Australien.ogg on the page wikt:Australien. Description of the error is that the file does not play till its end. I tried to listen to it on a different browser and open the page of the file itself, but the issue persists. However, when I used the native player of both browsers, it played till the end. If this is not the right place for this complaint, then feel free to move it anywhere, because I couldn't find it. --Mahmudmasri (talk) 01:43, 13 October 2017 (UTC)

Phabricator would be the right place for technical problems. Other files in the same category seem to play correctly to the end. --ghouston (talk) 11:11, 13 October 2017 (UTC)

CatScan not working?Edit

Category:Meta categories has a CatScan link on it that I often use, but today it has been failing. It gives the messages "502 Bad Gateway" and "nginx/1.11.13". Usually when I get that message, it works again after a minute or so, but not today. Can anyone shed light on what the problem is? --Auntof6 (talk) 06:27, 13 October 2017 (UTC)

Never mind: it's working again. --Auntof6 (talk) 08:50, 13 October 2017 (UTC)

Focus group for Structured Commons - please consider joining!Edit

Hello all! For the upcoming development of Structured Data on Commons, I notice that it would be very helpful for me (and the entire Structured Commons team) to be able to work with a group of dedicated community members whom we can approach for input regularly. Consider it a group of people who are OK to be pinged every now and then with (smaller) requests for feedback (not for larger decision-making, which should take place with the Commons community at large). So I would like to experiment with a focus group (see more info here). We can figure out how we can work best as we go along! I'd very much appreciate it if people who are very interested in Structured Commons would consider signing up. Many thanks! SandraF (WMF) (talk) 11:41, 13 October 2017 (UTC)

This is the future of Commons and other projects, and the future is thrilling. Not only will this offer powerful complements to our existing descriptions and categories, but it will allow for automated processing that I cannot even dream of yet. Thank you very much for your work, I hope that we will be able to contribute to it! Rama (talk) 12:00, 13 October 2017 (UTC)
Yes, I can't wait to type up all the climate data. Structured data is awesome! I love the concept (so far) Sign me up! C(_) --Hedwig in Washington (mail?) 23:09, 13 October 2017 (UTC)

October 14Edit

looking for a two photographersEdit

I am looking for a two photographers who can take quality pictures of paintings in Flensburg and Helsinki. Do you know any photografers in these towns or near them? Can you help?

best wishes Villy Fink Isaksen / User:Villy_Fink_Isaksen

Hi, you might want to take a look at Category:Users in Finland since they may not read this page, and contact directly those who are nearest. Cheers. Rodhullandemu (talk) 13:21, 14 October 2017 (UTC)
Have a look here Gruss --Nightflyer (talk) 13:27, 14 October 2017 (UTC)
(Found this thread by accident) You can ask from Finnish users at Commons:Kahvihuone here on Commons, or in Finnish Wikipedia's village pump at w:fi:Wikipedia:Kahvihuone_(sekalaista). Stryn (talk) 16:10, 14 October 2017 (UTC)
Thanks. --Villy Fink Isaksen (talk) 23:47, 15 October 2017 (UTC)

Policies for map geo-data stored in the Data: namespaceEdit

A recent deletion request pinpoints several open problems in licensing geo-data stored in the Data: namespace. I believe that the following aspects should be clarified:

  • Should Data: namespace allow CC-BY-SA licenses? Currently, it only allows the data under CC-0, which parallels Wikidata licensing, because numerical data and simple text statements are trivial by default. Many Wikidata entries are imported from Wikipedia pages, which are licensed under CC-BY-SA. Nevertheless, Wikidata is always CC-0, even if trivial content from Wikipedia is included.
  • How to verify the map source? Most of the geo-data are traced from existing maps. Here, one says explicitly none of Renek78's uploads to Wikimedia Commons should be trusted and should be deleted as copyright violations unless fully verified otherwise. What does this "full verification" mean? Should I make screenshots during the tracing? How many of such screenshots are necessary to verify the source?
  • What is the originality threshold? If I include parts of a map boundary from an external source, such as OpenStreetMap, what does create a derivative work? Is one single point of a boundary a copyrightable object? If I add a point [X1,Y1] that is similar to the point [X2,Y2] in OpenStreetMap, what difference between these two points renders them distinguishable from license point of view?

A clear answer to these questions crafted into a new policy is vital for using the Data: namespace, for example in Wikivoyage. We are not part of the local community and can not create our own policies here. Therefore, I request a support of an experienced Commons user who can guide this discussion and transform its outcome into an established policy. Thank you! --Alexander (talk) 15:01, 14 October 2017 (UTC)

Just to be clear, as the quote is out of context, when I wrote "none of Renek78's uploads to Wikimedia Commons should be trusted", that was because they deliberately lied about importing CC-BY-SA maps by declaring them CC0 and "own work". After a massive waste of volunteer time and energy on Commons and Wikivoyage, they confessed to lying. At the current time Commons is still hosting those files and allowing reuse as CC0. This breaks the terms of Open Street Map which requires attribution and must be fixed with urgency, not left hanging around while extended hypothetical debate attempts to redefine our understanding of what COM:DW means for maps. -- (talk) 22:30, 14 October 2017 (UTC)
I would kindly ask you to avoid discussing that particular deletion request here and focus on the general questions that I raised. The deletion request can be discussed on its relevant page. --Alexander (talk) 23:13, 14 October 2017 (UTC)
That's a ridiculous misrepresentaton of what actually happened. Powers (talk) 14:43, 15 October 2017 (UTC)
  • Pictogram voting comment.svg Comment Correction to the above comments, OSM data is licensed under the Open Database License, "ODbL" not CC-BY-SA. Prior to September 2012 OSM data was licensed under CC-BY-SA, but that is no more and only applies to that old data set which is available from archives, that doesn't apply to current OSM data. If you were to copy OSM map tiles (not data), those are licensed CC-BY-SA. I just want it to be clear that OSM data currently is licensed Open Database License, "ODbL". - Offnfopt(talk) 00:22, 15 October 2017 (UTC)
  • Yes, though as this includes "Attribution and Share-Alike" the legal constraint is almost identical. -- (talk) 10:22, 15 October 2017 (UTC)
  • Offnfopt, thank you. Two questions in this respect: i) do I read it correctly that Commons also allows the ODbL license? ii) if map data are under one license, and map tiles are under a different license, what is the relation? --Alexander (talk) 10:37, 15 October 2017 (UTC)
Alexander map data is just the raw information, the tiles are pieces of a map generated by OSM with the map data. Commons allows ODbL, though just not in the data namespace as you've seen. See T154071. We have two templates for ODbl {{ODbL}} and {{ODbL OpenStreetMap}} -- Offnfopt(talk) 21:46, 16 October 2017 (UTC)

With regards to "Should Data namespace allow CC-BY-SA licenses?", I think it is helpful to separate policy from current technical limitations. I may be wrong, but I don't think, as a matter of principle, that the Commons community is opposed to the Data namespace making use of other licenses that comply with the Commons licensing policy. It is my understanding that the limitation to the use of only the CC0 license was done by the developers because they have not yet implemented support for tracking and propogating the license metadata needed to comply with licenses that have attribution requirements, license link requirements, etc. Furthermore, adding proper support for databases/maps built from data from multiple sources not only requires a method of properly attributing the sources and linking to their licenses but also determining when a database/map is a collection or an adaptation and thus having to confront the issue of license compatibility. Commons has long had to deal with this issue with regards to collages. Adoption of multi-licensing was used to ease some of these license compatibly issues. It is not terribly surprising that the developers chose to start by just supporting the CC0 license, as CC0 databases can be freely intermixed without any concern for attribution or license issues. I'd actually be interested in hearing if anyone is actually opposed to the support of additional licenses in Data namespaces solely on a principle that is unrelated to any current or future technical restrictions. —RP88 (talk) 10:11, 15 October 2017 (UTC)

I definitely support going to the CC-BY license, and, if there is consensus in this discussion, we can just open a phabricator ticket.--Ymblanter (talk) 10:23, 15 October 2017 (UTC)
RP88, thank you for the insight. A priori I am not sure who is supportive of what here. Moreover, technical development is unlikely to happen on its own. The community should demonstrate its interest and demand. --Alexander (talk) 10:37, 15 October 2017 (UTC)
Personally I would be happy to see support added to the Data namespace for any Commons-compatable license, so long as the support includes the features necessary to comply with the terms of the license. —RP88 (talk) 11:25, 15 October 2017 (UTC)

With regards to "What is the originality threshold?", I think it might be helpful to distinguish between what Commons is legally obliged to consider (i.e. US law by virtue of WMF hosting) and what we consider by virtue of Commons licensing policy (currently both US and country of origin). Before we can even decide where the threshold lies for a database/map, we need to decide which country's threshold we are going to apply. This seems like a particularly thorny issue for databases/maps that are built from data from multiple sources. Should we evaluate content imported from OpenStreetMap under UK law (which has a very low threshold of originality) due to the OpenStreetMap Foundation being a UK organization, or should we examine the country of origin of the OSM contributor(s) (if that is even determinable) of the data actually imported? Commons occasionally has adopted exceptions to its general policy of requiring content be free in both the US and country of origin (e.g. US only for faithful reproductions of PD works and country of origin only for freedom of panorama). Absent a change in policy, given the very low threshold of originality in the UK, I think we're obliged under current Commons policy to consider an extraction of even just a few points from OSM to be above the threshold of originality. —RP88 (talk) 11:25, 15 October 2017 (UTC)

Though it may seem extreme, even two geo-coordinates from OSM means that in practice one is dealing with 4 digits, each with seven decimal accuracy. It is not possible to later claim that there was no creativity in picking these locations to describe an object, even if just a short straight line as part of a boundary, unless these physical locations were impossible to place nearby apart from the exact same seven decimal level of precision. Cartography has always been a key part of copyright law and history, there is no doubt that the courts consider maps creative works, and even tiny extracts may be subject to legal protection.
However I am unaware of anyone ever claiming that a single pair of coordinates describing one physical point is copyright-able. Neither has anyone published a file on Commons that consisted of such a thing, probably as it would be out of scope to publish files of that type.
With regard to changing how licensing of the Data namespace should work, that would be better as a firm Proposal with a vote, rather than an open free-range discussion like this. There are good reasons why pure JSON datasets should be CC0, and these should be brought out in a proposal, for example future-proofing compatibility with Wikidata and the high likelihood that Commons JSON datasets will be harvested by commercial reusers without mechanisms for correct attribution. -- (talk) 12:05, 15 October 2017 (UTC)
That isn't "seven decimal accuracy". That's seven digits of false precision. The least significant digits are random and spurious, they convey neither "skill", "imagination" nor useful data. Adding a few digits of random gibberish doesn't magically make uncopyrightable facts copyrightable. K7L (talk) 12:02, 18 October 2017 (UTC)
The law disagrees with you, based on the history of court judgements, plus the fact is that contributors to OpenStreetMap who use the visual tools to add points and connectors are acting with human skill and judgement, not randomly or as automata. -- (talk) 12:13, 18 October 2017 (UTC)

I have kicked off a proposal for Commons to allow non-CC0 license in the Data namespace, which would solve all of the issues that have arisen. I suggest that discussion about whether geocoordinates are copyrightable is tangential to the proposal, that would be a discussion to change the fundamental undertanding of how COM:L works for digital creations of any kind.

Refer to Commons:Village pump/Proposals#Proposal to include non-CC0 licenses for the Data namespace. -- (talk) 12:13, 18 October 2017 (UTC)

Category:Modern movement architectureEdit

Isn't it better to call this category "Modernist architecture"? --Stolbovsky (talk) 19:15, 14 October 2017 (UTC)

I think so, see Commons:Categories for discussion/2014/01/Category:Modern movement in the United States. --ghouston (talk) 23:54, 14 October 2017 (UTC)

Image viewer fails to load most images on Category:Boise_RiverEdit

Using Google Chrome, I did the following:

Loaded https://commons.wikimedia.org/wiki/Category:Boise_River

From the image viewer dropdown, selected "All images"

Waited for the images to load. But the vast majority never load.

Does anyone else have this problem?

Looking in the developer console, I see a bunch of HTTP 429 "too many requests" errors. It seems that the image viewer is being more aggressive than your servers allow in attempting to load the images. When the image viewer code gets the 429 errors it seems to give up. A more typical approach might be to use exponential backoff to space requests increasingly far apart until they stop being denied. Also, it would probably make more sense to only do a limited number of image requests at a time, whereas right now it seems to try to load them all at once.

The image viewer tool (not sure if that's what it's really called) is one of my favorite features of Wikimedia Commons. Hoping this issue can be resolved soon!

  • I use Google Chrome for Mac. It took two seconds to display all the images in that category. When I clicked on "More" it took longer, about 10 seconds. Wikimandia (talk) 04:15, 15 October 2017 (UTC)
It works fine for me. Ruslik (talk) 19:04, 15 October 2017 (UTC)

October 15Edit

File:Het Nationaal Monument in wording.ogvEdit

Anybody here I can address myself to in Dutch if need be? The thing is, trying to fix a typo in that file: "verzetstrijders" --> "verzetsstrijders" the letter "s" appears somewhere else in the text. Also, in trying to make some interwikilinks, the text gets all weird. Is there any explanation for that or is it me being stupid? Thank you for your time. Lotje (talk) 22:51, 15 October 2017 (UTC)

@Lotje: Better? --Hedwig in Washington (mail?) 23:16, 15 October 2017 (UTC)
@Hedwig in Washington:, how come you were able to fix it and I could not? Things have changed recently with editing modus on commons and I cannot figure out how to deal with it. BTW, I did not receive your pinged message. Hence I ping you to see if it works. Thank you for your time.Lotje (talk) 10:59, 16 October 2017 (UTC)

October 16Edit

Higher resolution uploadEdit

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 [5] [6] (previous discussion). But Denniss states that it is wrong. What community can say on this topic? — Vort (talk) 12:55, 16 October 2017 (UTC)

@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)
@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)
@Jeff G., 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)
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)
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)
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)
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)
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)
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)
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)
"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)
"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)
"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)
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)
"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)
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:
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)
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)
"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)
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)
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)
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)
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)

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

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

Tech News: 2017-42Edit

15:31, 16 October 2017 (UTC)

Looking for small tasks+mentors for new contributors - got something in mind?Edit

Hi everybody! Google Code-in (GCI) will soon take place again - a seven week long contest for 13-17 year old students to contribute to free software projects. Tasks should take an experienced contributed about two-three hours and can be of the categories Code, Documentation/Training, Outreach/Research, Quality Assurance, and User Interface/Design. Do you have an idea for a task and could you imagine mentoring that task? For example, do you have something on mind that needs documentation, research, some gadget or template issues on your "To do" list but you never had the time, and can imagine enjoying mentoring such a task to help a new contributor? If yes, please check out mw:Google Code-in/2017 and become a mentor! Thanks in advance! --AKlapper (WMF) (talk) 19:50, 16 October 2017 (UTC)

October 17Edit

Date searchEdit

Is it possible to search for pictures of a certain date? Rudolphous (talk) 07:19, 17 October 2017 (UTC)

You can search for something like "18 October 2016", with the quotes. --ghouston (talk) 01:32, 18 October 2017 (UTC)
It will give some false matches though, of text like "automatically reviewed on 18 October 2016 by Panoramio upload bot". --ghouston (talk) 01:35, 18 October 2017 (UTC)

Image identificationEdit

There is a question on File_talk:Margaret_of_Burgundy.jpg, which I can not answer. Somebody more familiar than me with French history needs to answer it. Ruslik (talk) 20:21, 17 October 2017 (UTC)

October 18Edit