(Mac OSX, Firefox, OpenRefine 3.7 beta2)
Wikidata reconciliation is working fine, but when I go to reconcile image filenames, choose “Add standard service…” and paste “https://commonsreconcile.toolforge.org/en/api”, I get an error:
Guess Types query failed error : java.o.IOException: HTTP error
400 : BAD REQUEST for URL /en/api
Any ideas what’s happening? I successfully uploaded images using OpenRefine a month ago, and that was using the previous snapshot version.
Toolforge had some technical issues earlier today, so I would suggest trying again.
Tried again, 12 hours later; same error.
OK, it’s nothing to do with Toolforge. I have my desktop and laptop open side by side; same OS, save version of Firefox, same version of OpenRefine. On the laptop I can add the Commons service and successfully reconcile images; on the desktop I get that error message. Will now try exporting the projects and images and swapping them between desktop and laptop to see if it’s some problem with the project, or with my desktop setup. Very frustrating.
========
OK, have swapped over projects, and it’s the project not the platform. One of the projects can reconcile its image list against Commons, but this European sketches one gives the error message. What meaningful differences might there be between projects that could be causing this?
Solved! Non-ASCII characters in three of the file names, a problem Sandra previously identified in August: ⚓ T315569 Guess Types query failed error : java.io.IOException: HTTP error 400 : BAD REQUEST for URL /en/api
After a few false starts, everything finally worked and the images are successfully uploaded. It would be worth noting in the Help that Commons reconciliation with OpenRefine requires ASCII filenames; Commons itself is fine with UTF-8, and non ASCII characters are common in English, such as macron with NZ English placenames.
Thanks for both reporting and resolving the problem locally @Adzebill. From what’s reported here and on the Phabricator issue T315569 that it seems most likely to me the problem lies with with the resolver rather than with OpenRefine. I do note that what your report here is slightly more general than T315569 which only mentions unprintable characters.
I wonder if there is any information you can share from the OpenRefine logs (as was shared in T315569) so we can see what the request was from OpenRefine that caused the failure?