In T299706#7638413, @DSGalaktos wrote:

The parser limit report doesn’t indicate that any limits were hit: I failed to notice that the “post-expand include size” was in fact exhausted:

I’m not sure if this is a regression or not, it’s possible long pages have always behaved this way and I just didn’t notice before. (I didn’t find any related Phabricator tasks, though.)

FWIW, there was also a bit of discussion about this on PC following the initial WDQS Beta announcement: https://www.wikidata.org/wiki/Wikidata:Project_chat/Archive/2015/09#Wikidata_Query_Service

I’ve created a test page at https://en.wikipedia.org/wiki/User:Galaktos/T130508.

do we actually have identifiers on properties?

Are catalog codes (P528) also identifiers in this scheme? Currently, it’s unclear whether catalog code statements (with the catalog itself as qualifier) should include the catalog prefix or not (e. g. “BWV 565” vs just “565”), so I’d be very happy if this new datatype could solve that problem as well.

Interesting, thank you very much for that information. I didn’t know NoScript did that kind of protection.

Hey, not so fast, I didn’t even file a bug there yet :(

The issue seems to be caused by NoScript. Disabling and Enabling NoScript removes and restores the problem.

Oh, interesting. I did a restart with Add-Ons disabled, and started in Safe Mode (whatever that does), and now I don’t get redirected. (I’m still logged in, so the session should be the same.)

Firefox 42.0a2 (2015-08-18), i. e. current Developer Edition, on Linux. But as I said, when I log in from a second browser profile (same browser), I can’t reproduce it either, so it’s probably specific to my current session. (I can still reproduce it in my main profile.)

If I log in from another browser profile, I don’t experience this bug, so I suspect my session in my main browser profile is somehow borked. I’ll try keeping that session alive, so that we have some way of reproducing this bug.

More specifically, the redirect is HTTP 301: Moved Permanently.

Seems to be fixed, thanks!

@danial: I don’t think ±1 is for some reason a better default for measured values than any other (±0.5, ±10, whatever). I think it would make more sense to mandate an explicit accuracy (with a helpful error message if missing, and possibly populating the text field with “±0”).

Hm, doesn’t work when removing statements or references (but does work when removing qualifiers).

Seems to be working now! Thanks!