Mar 3 2020
Jan 30 2020
UI which has the capacity to mangle input and demands that the user must do something beyond their simple input of the date, is unambiguously, categorically and unimpeachably broken. It should be considered as such.
We could maybe have a preference, such that the user can specify whether they want date parsing to be based on an assumption of MM/DD/YYYY or DD/MM/YYYY. Stop guessing. Ask the users.
Jan 5 2020
Is there a problem with increasing the size limit. It /seems/ like a very easy quickwin. What's the story?
Jan 4 2020
Wikidata currently gets ~660k edits per day.
Nov 21 2019
Notable that WDQS lag seems to be paying not a blind bit of notice to this change :(
Nov 7 2019
Per Laske, SPARQL for this issue in Germany [https://www.wikidata.org/wiki/Wikidata:Contact_the_development_team#Surplus_of_coordinates_-_T198078]
Nov 6 2019
Ditto http://www.wikidata.org/entity/Q17567523 ... there are probably others.
Oct 23 2019
And note Ethan's assertion: The scheme for Geonames URIs requires a trailing forward slash.
Oct 19 2019
Fix by all means, but I note "It is an error for aggregates to project variables with a name already used in other aggregate projections, or in the WHERE clause." https://www.w3.org/TR/sparql11-query/#aggregateExample
Sep 16 2019
Tested - works for me in situation in which it previously didn't work.
Sep 13 2019
Sep 1 2019
Can I gently detach this issue, somewhat, from disputed territory. The current situation is that maps served by Wikipedias & (my key use) Wikidata WDQS use "OSM Bright for Mapbox Studio" tiles ( https://foundation.wikimedia.org/wiki/Maps_Terms_of_Use#Where_does_the_map_data_come_from? )
Jul 20 2019
Worth noting that user:Twofivesixbot
Jun 16 2019
May 30 2019
May 21 2019
Seems more likely it's a data input issue than a query issue @matej_suchanek, given that WDQS doesn't exhibit the same sort of error for analogous wdtn:, such as wdtn:P244 (Library of Congress authority ID) - see for instance https://w.wiki/48X
de link is showing. local caching issue for @FriedhelmW ?
May 17 2019
May 15 2019
+1 for this. Further example of a long SPARQL report is at https://twitter.com/Tagishsimon/status/1128769104674996234 fwiw
May 2 2019
And the clear risk with this issue is that if one enters a search term that should get a match ... for instance - Judith Schwarz - and places a reliance on the dropdown, then seeing no dropdown, as if the search term did not match anything, will, for instance, lead to the creation of duplicates.
Apr 30 2019
Apr 29 2019
Apr 27 2019
Apr 5 2019
Feb 26 2019
That's not a fix, so much as a helpful workaround.
closed as duplicate of or subsumed within T214984
@Aklapper thanks - I've moved the contents to that ticket & will close this.
Let me add content from << T217103: Extension:Kartographer producing "Couldn't parse JSON" errors when SPARQL includes queryhints >> since this seems a part of the issue raised here and may provide an additional failure-mode example:
Feb 25 2019
Feb 16 2019
No, I'll not be doing that, any more than you just have. Whilst a serious outage is being treated merely as a curiosity, it is well worth reminding WMF employees that outages like this are far from acceptable.
Day 2 of no Quickstatements, no Listeria, no ETA for a resumption of service ... no comment from WMF on why what is a critical service - if we're taking this whole wikidata business at all seriously - is fritzed.
Feb 1 2019
And to prove the curate's egg, http://petscan.wmflabs.org/?psid=7075446&al_commands=P31%3AQ5%0AP21%3AQ6581072 when run again, 502d.
Mixed results. The following three worked like a charm:
Sorry to burden you with this. As a user 502s are v.frustrating, but I can also imagine it's v.frustrating for you to be asked to debug when you could be making snowmen instead.
502 examples in the last couple of minutes:
Thanks Magnus. I run those two daily; get perhaps 20% 502s, without an obvious pattern. There are others (e.g. listed on https://en.wikipedia.org/wiki/Wikipedia:WikiProject_Women_in_Red/Metrics/Wikidata ) which more reliably 502
How about we work out what's going on BEFORE we peremptorally close this issue. "As far as I know" does not cut it.
Ideally Cloud-Services will liaise with @Magnus either to bottom out & solve the issue; or else to provide an explanation for the 502 issue which we can use to console ourselves each time it happens.
Jan 31 2019
So far as I know, the fault is not with Petscan, but with the WMF infrastructure on which it operates. Please do not be so hasty to dismiss problems like this.
Jan 26 2019
Jan 21 2019
Jan 16 2019
Nov 20 2018
@Jdlrobson Do we need to provide a description? Would not <meta name="twitter:card" content="title"/> provide our extant <title></title> contents to the twitter card. (I really don't know, but from first principles that seems to be what specifying content="title" would be likely to do.)
Is it really blocked, or is the best driving out the good? Would not something as simple as <meta name="twitter:card" content="title"/> be a massive improvement on the current highly suboptimal rendering - example: https://twitter.com/Tagishsimon/status/1064868689995071488
Nov 8 2018
Nov 7 2018
Nov 4 2018
Thx @LucasWerkmeister. All makes sense now :)
Oct 27 2018
My regex is not great, but \?(\S*?)[\s\)}\.]
@Jonas - is there not a pattern that we could use instead of /^[\w\d]*/ ... we have a questionmark followed by not white space followed by a space or by ) or } or .
Oct 21 2018
Oct 19 2018
Sep 12 2018
Aug 20 2018
Jul 28 2018
This issue is still occurring, lest anyone think we're done. I just got it on https://www.wikidata.org/wiki/Q55471970 when logged in.
Jul 27 2018
see also T193214 which has a similar URL encoding issue.
You probably want to specify the issue here, Salgo60, rather than hope that the URL you provided will work in, say, 2 weeks time. (Hint: it won't.) The post in question says:
May 29 2018
I think it might fall into the category of "being able to search for a formula without knowledge of the arcane ways in which it was mangled downstream of data entry".