Dec 17 2020
Looking into this a bit more, it seems to be down to a bug on line 79 of mw.FlickrChecker.js. This currently has:
Nov 23 2020
It has occurred to me today that this problem is (in some ways) a blessing in disguise - it helps mitigate against the effects of vandalism by deleting or changing a formatter URL.
Nov 10 2020
I flagged up the other case mentioned. As an example of the issue -
Aug 24 2020
Aug 7 2020
A way to get access in WDQS to "original calendar" values would really be helpful.
Jul 17 2020
I believe the code governing this is in https://gerrit.wikimedia.org/r/plugins/gitiles/wikidata/query/gui/+/refs/heads/master/wikibase/queryService/ui/resultBrowser/ImageResultBrowser.js#245 (lines 245-7)
May 19 2020
Looks like the test queries above are all returning the "normal" expected results now - hopefully this means the reload has fixed things!
May 1 2020
As an interim workaround, I've put together a quick-and-dirty script to slowly do a rolling purge of items using pywikibot. It identifies all items that have not been edited since before the formatter URL was changed, generates a list, and works through them. As it uses the PWB framework it respects maxlag, and will back off if overloaded.
Apr 25 2020
Apr 8 2020
Apr 4 2020
Mar 6 2020
Feb 12 2020
Possibly related to this? T44964
Nov 7 2019
This is affecting recent changes as well as the watchlist.
Sep 13 2019
Sep 11 2019
Sep 7 2019
I'm still getting this with "normal" properties (ie not just wikibase:quantityUnit) on https://www.wikidata.org/wiki/Q334443 - it's showing up as a duplicate as 'P334443' in P39-based searches which return the item, and I can replicate this just with a targeted search by identifier (https://w.wiki/825).
Aug 1 2019
Another option would be to have differential rate limits - 2k in general, longer links only allowed for query.wikidata.org URLs? (suggestion from Stefano)
Jul 24 2019
Apr 20 2019
@GoranSMilovanovic oh hurrah - glad you've traced the problem! Those numbers for P1614 sound pretty much what I'd expect given it's data from February, so it looks like it's solved. Thanks for this, the dashboard looks like a really useful tool :-)
Apr 16 2019
@GoranSMilovanovic thanks! Looking back at my tests for P.1614, these are the new numbers in the overlap data column (tables view, left hand column). They're a lot higher, but I think they're still incomplete.
Apr 15 2019
@GoranSMilovanovic - I can confirm that the numbers on the tables seem a bit off for some other properties. I've been looking at P1614 (History of Parliament), which is complete and fairly stable. It currently has 21428 IDs on 17942 items (there's a lot of items with two/three IDs) and hasn't had any big changes since I finished matching in mid-2018.
Apr 12 2019
This would help solve another problem - at the moment the existing third-party shortener embedded in the query service returns a 431 error for queries which are longer than ~3000 characters.
Nov 2 2018
To follow up on @Jheald and @Lydia_Pintscher's comments here - for a lot of use-cases, I agree that a lag measured in a few hours isn't much of a problem, because the underlying data is fairly static. Most property values don't change minute-to-minute or even month-to-month, most ontologies and hierarchies are reasonably stable, and so on. Queries which are "tell me something interesting about the underlying data" will tend to return reasonably good results whatever the update lag, assuming that it's not something that changes frequently or has been recently worked on.
Sep 24 2018
Can confirm I've just had it on https://www.wikidata.org/wiki/Q29201051 as well.
Can confirm that my experience (probably on ~20 Sept if that helps narrow it down; Firefox 62 under Ubuntu) was as Magnus describes it. It happened on one or two pages; I haven't had it happen since and assumed it was some weird local browser issue so didn't file a bug for it.
Aug 3 2018
Aug 2 2018
Jan 23 2018
One other sorting method that might be useful - P1545 qualifiers on P2093 claims (used for huge numbers of scholarly articles) or P735 claims (starting to become common for people with first and middle names). It looks like we will need a general solution for sorting properties by qualifier...
Jan 18 2018
We might need to sort on more qualifiers than just P585. This is becoming an issue for P39 claims, where it's not unknown for someone to have 10-20 claims or even more if they had a long career (especially in politics where they might hold a lot of different official posts and elected offices).
Oct 16 2017
Oct 15 2017
[Apologies - forgot to ever put in a response to this. Thanks for looking into it.]
Jun 28 2017
This all sounds great until...
Jun 13 2017
Dec 8 2016
We had this problem appear today at an outreach event - it was triggering for several new users on the Spanish Wikipedia when they tried to add URLs into sandbox pages. The captchas looped endlessly whether the input was correct or not.
Oct 30 2016
Aug 30 2016
Checked using a different tool (edit made through PetScan/WIDAR) - different browser & computer to last time, and different account to previous report. It has "Add pages and files I edit to my watchlist", "Add pages and files I move to my watchlist", and "Add pages I create and files I upload to my watchlist" ticked in preferences.
Aug 21 2016
Jul 31 2016
Here's one I did this evening:
Jun 10 2016
See also https://phabricator.wikimedia.org/T117763 - suggesting allowing (Q123) as a valid entry as well as Q123.
May 30 2016
This would be very useful for reports which use Quarry data (allowing us to timestamp the source for the end-user). The page currently reports the ID of the last run (in the source as "qrun_id": 12345) which is part-way there, but a date would be really handy.
May 24 2016
May 11 2016
May 4 2016
Mar 24 2016
Focusing specifically on WP0 uploaders doesn't seem to be the most effective approach here - there'd be nothing stopping a small number of non-WP0 users seeding this content onto Commons for anyone else to retrieve. (Likewise, there's no particular reason the downloaders have to be on WP0).
Nov 11 2015
This is a good idea, I think.
Nov 5 2015
Nov 4 2015
Sep 29 2015
Sep 19 2015
This appears to be browser-dependent. In Chrome (45), alt-S successfully saves. However, in Firefox (40), alt-S opens the history menu. (Both checked under xubuntu 14.04)
Sep 16 2015
Jan 7 2015
I'd agree with Technical13 - in general terms, it's reasonable for the notice to come up if an actual *edit* has been reverted, as it'd be very hard for the system to distinguish between ones someone needs to know about and ones they don't.