yeah sorry I understand now. I believe that I and the two other people on telegram were confused and thought you could pass a url (and not the literal string "url") as a value for "props".

this post on telegram seems to explain (https://t.me/c/1224298920/123559) but it's still very confusing. maybe just remove this option? or deprecate?

Hey thanks for taking a look. I see I was unaware you could do that in a spec. It's cool that you provide a built version of the document (I wasn't able to find that before). Unfortunately it also fails on that version and dereferencing doesn't work either. Guess it's a bug in the generator (makes sense since it's not a very common pattern). I'm gonna just code this partially by hand I guess. Yeah I saw that there were some libraries for js/ts but I need a python library and I guess openapi support there is less mature.

Would it be difficult to publicly release the data collected so far?

if there is no English label then there is no link to the item.

Sometimes when I click on a button to make a decision there is no change to indicate anything has happened. Then I press the button again and nothing happens. And then a little while later the button changes to "Marked as". Probably should hide the button while a request is being waited on because looking at the network tab it seems like you're getting a bunch of duplicate messages because of this.

did you change the order of the buttons? i swear keep was on the left before. are. you intentionally shuffling them?

edits to the various sandboxes should be excluded.

Clicking on links in the rendered revision diff information section takes you to a 404. This is important because descriptions of the items aren't shown so you can't tell the difference between two items with the same name.

Might I suggest if we're going to re-run it to add occupation (P106) to the list of classifying properties. it would be useful if it suggested sport for sports people or position held for politicians etc

Ok I have no idea what changed but I refreshed the page for the nth time and now I'm logged in. So I guess this is resolved.

ok looking at T226797 I see that maybe this is a known issue? I tried click the firefox shield and turning off enhances protection (strict mode isn't enabled) and it still didn't work

that said it's preferable to merge the current fix

yeah this works better. now it throws an exception on server timeouts. but it isn't throwing exceptions on malformed SPARQL. e.g.

That's probably because you have your timeout in user-config.py is too low. The default value probably also is too low. If you set

sure. here's a query that reliably times out:

I am using requests version "2.28.1".

The cause of the bug is this line in sparql.py. It's not clear to me how big the blast radius from fixing it there would be. Probably big.

So zooming would be an ok solution.

I don't think this ticket is a duplicate of that one. I'm not asking for more precise time. I'm asking for the parser to be more forgiving before truncating the time to a day.