That's very interesting - there have only been about 162k days since the Gregorian calendar came in (62k days of which were in the "dual calendar" period) which even allowing for some year/month precision and some future dates, strongly suggests a pretty significant chunk of those Gregorian-marked dates are going to be during the Julian era. Will be quite the cleanup challenge at some point!

Just posted this onwiki but to keep it all on one place - it looks like there are still 484k items with Akan labels (plus another 146k descriptions and 173k aliases, but I'm guessing those also have labels).

haslabel:ak now gives an error even though there are thousands of items with ak labels.

@Delane13 It is possible to do this conversion within the SPARQL service - approximately, you would want something like this query, tweaking the calendar offsets as needed. It is a mess, but it does seem to work. Note that it's possible to retrieve the precision, it's just not default-displayed (much like calendars...)

@Tagishsimon I *think* that is a subtly different problem, connected to the deletion not being done quickly enough for the moved sitelink to catch up?

@dcausse For the sample here (enwiki FAs) it affects ~0.1% over the course of a year, and presumably older ones are being swept up by the reloads. I think that's reasonable enough to file as "a rare problem" if the alternative would cause performance issues.

There are two issues that I noted during the page-count problems the other month, and neither are a blocker here but if we're changing content namespaces it might be a good time to think about them -

Maybe something like:

In recent months, there have been inaccurate numbers shown for various [[Special:Statistics]] at Commons, Wikidata, and English Wikipedia. This has now been fixed.

Thanks so much for dealing with this so promptly! Will the update script need to be run on Commons as well?

After looking at this afresh I think part of my first suggestion is moot: it is possible to get an indication of the calendar model in use for a given statement by using wikibase:timeCalendarModel (see eg https://w.wiki/5MPi for the "point in time" of the October Revolution, which currently has both Julian and Gregorian dates), I hadn't properly understood this.

This would be useful for copy-pasting, but how would it interact with people manually typing IDs?

In T285076#7163976, @Amire80 wrote:

LangcoM.

Looks good to me, I guess, although I am curious about the source. Do these appear in a dictionary?

I am still seeing a handful of inconsistencies stemming from the same period of edits. For example this edit to Q5540133 on 23 December has not propagated to all databases, and so https://w.wiki/w66 returns a missing value for one of the "partyLabel" fields about one time in four.

Looking into this a bit more, it seems to be down to a bug on line 79 of mw.FlickrChecker.js. This currently has:

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.

I flagged up the other case mentioned. As an example of the issue -

In T112081#6404998, @valerio.bozzolan wrote:

A way to get access in WDQS to "original calendar" values would really be helpful.

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)

Looks like the test queries above are all returning the "normal" expected results now - hopefully this means the reload has fixed things!

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.

Possibly related to this? T44964

This is affecting recent changes as well as the watchlist.

In T215073#5456845, @Tagishsimon wrote:

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

Another option would be to have differential rate limits - 2k in general, longer links only allowed for query.wikidata.org URLs? (suggestion from Stefano)

In T220703#5107541, @Habitator_terrae wrote:

If the link lenght would be grow up to 4000, link like w.wiki/uR (an File in Base64 code between []) would become more effective. So it could be missused for sharing also other content, that has nothing to do with wikimedia. This very problematic, because the size of the short links grow, when the size of the numbers of the short links grow. And I don't see how Steward could fix this alone.

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

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

In T204440#5112446, @GoranSMilovanovic wrote:

@agray

For VIAF (P214) the dashboard reports 440 items, against a SPARQL total of 2807.

• For VIAF P214, the dashboard reports 1380767 items (tab: Tables, the table to the right, search for this identifier); are comparing the same data? What dashboard functionality have you used to find 440 items for P214 VIAF, please?

For Hansard ID (P2015), the dashboard has 110 and a SPARQL query has 2369.

• For Hansard ID (P2015), the dashboard reports 14467 items, and overlap of 355 items with P214 VIAF ID. Are we looking at the same dashboard? :)

Most dramatically, for the Oxford DNB (P1415), the dashboard has two items and SPARQL has 3171.

• For the Oxford DNB (P1415) the dashboard reports that 61143 items make use of it. Can you share your SPARQL queries, because I think we are discussing different datasets here.

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

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.

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.

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.

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...

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

[Apologies - forgot to ever put in a response to this. Thanks for looking into it.]

This all sounds great until...

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.

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.

Here's one I did this evening:

See also https://phabricator.wikimedia.org/T117763 - suggesting allowing (Q123) as a valid entry as well as Q123.

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.

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

This is a good idea, I think.

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)

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.