User Details
- User Since
- Feb 22 2021, 12:15 PM (262 w, 5 d)
- Availability
- Available
- LDAP User
- Unknown
- MediaWiki User
- Botoxparty [ Global Accounts ]
Oct 16 2023
@conny-kawohl_WMDE I will send an email to ca@wikimedia.org and CC you
Oct 11 2023
Dec 13 2021
- Does not include shortening of URLs (see Query Service URL shortener)
Jun 2 2021
Yay 🍾 So cool to see this live!
May 7 2021
Ok no problem will add that in. Any updates on the live url? 😇
May 5 2021
There's some discussion about whether the parameter should be #queryTitle or #title. Both are mentioned in the original report.
Apr 29 2021
Also still pending a code review from @Lucas_Werkmeister_WMDE
I don't have access to netlify to setup a redirect. ( I think a redirect would be appropriate in case anyone has bookmarked the netlify URL, and then can deprecate after 6 months).
Apr 28 2021
Please check the latest updates at the temp URL:
Apr 22 2021
Change request on Gerrit can be tracked here:
We can track the change request for this on Gerrit here:
Change request on Gerrit:
Apr 19 2021
Just pending the supply of the GIF for this.
Apr 18 2021
Apr 14 2021
Tool has been deployed to https://item-quality-evaluator.toolforge.org/ and the Netlify deploy has been removed from the repository.
Done! Please retest :)
Great pickup of this bug! Should be resolved in the latest deployment on https://item-quality-evaluator.toolforge.org/
@Jan_Dittrich These are ready for review on the live deployed environment: https://item-quality-evaluator.toolforge.org/
Apr 12 2021
Apr 7 2021
Mar 30 2021
Errors from Sparql requests will be handled the same as the wikidata-query-gui project:
Mar 29 2021
This is the implementation from Bootstrap, X on the right with a title.
Created another pull request to wikidata-query-gui to enable proper error handling for Sparql requests.
Mar 28 2021
Sample of CSV results file:
Mar 25 2021
Currently pending some code changes to the wikidata-query-gui repository to get this ticket over the line.
Mar 24 2021
Mar 23 2021
Mar 2 2021
Yep, we should be able to detect if its an error from a service vs. something internal in the application and have different messaging.
The error could appear if:
Review notes:
It is possible to create a bug report in Phabricator in a similar way. Would this come under a 'Bug report' or 'Production Error' ?
Mar 1 2021
I will offer another suggestion also, the user can directly report the issue to the GitHub project and capture the error messaging from the application.
I've generated the CSV using all the data that @Jan_Dittrich requested as it was already available to use.
I have also added the following alert if there was an issue with getting a response or processing the responses from the API:
