New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Error in API call #6
Comments
It may make sense to point the default rust bindings to one of the mirrors instead of libretranslate.com to take pressure off the main site. |
Yeah ideally any bindings library should allow developers to choose a host to point to (and to not default to libretranslate.com). We'd love to be able to provide a public API translation for everyone, but it's just not sustainable. You can still use the API endpoints from libretranslate.com, but now you need an API key for programmatic access. |
Makes perfect sense, @pierotofy. I'd suggest the requirement should be documented in the crate and a clearer error message be transmitted back. |
Hey thanks for all this, I'll make the changes now. |
Hey thanks for the issue, I should have solved the problem. You can now translate using a custom URL, as well as get better errors from the website. See the example. Does this fix your problem? @ToferC, @pierotofy & @PJ-Finlay |
Thanks @grantshandy - fixes look great. |
Hi Grant - first of all - great work on the crate. I had set it up and was using it in testing in an Actix-Web app and it was working well, but a few days ago it stopped working with the following error:
thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: ParseError("Unable to find translatedText in parsed JSON")', src/main.rs:172:101
I'm thinking there might have been a change in the LibreTranslate API
Here's the test snippet that mirrors my app:
The text was updated successfully, but these errors were encountered: