Skip to content
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

[Feature Request] LibreTranslate integration #2188

Closed
PJ-Finlay opened this issue Jun 2, 2021 · 11 comments
Closed

[Feature Request] LibreTranslate integration #2188

PJ-Finlay opened this issue Jun 2, 2021 · 11 comments
Assignees

Comments

@PJ-Finlay
Copy link

https://github.com/uav4geo/LibreTranslate

@adeekshith
Copy link

Also see #134

@connyduck
Copy link
Collaborator

I like this way more than previous suggestions that involved close-source apis.

Does anyone know what they charge for an api key? Or probably better, who can host an instance for us?

@a1batross
Copy link
Contributor

a1batross commented Jun 11, 2021

@connyduck
I can help with hosting, though it will be much better to have several fallback LibreTranslate servers.

Done. Server is live at https://translate.mentality.rip

@PJ-Finlay
Copy link
Author

You can buy API keys from the project which helps support future development! There are also mirrors and self hosting is always a good option.

@pierotofy

@connyduck
Copy link
Collaborator

If we hardcode an instance into Tusky, we will also need a privacy policy. I think it would be cool if the user can choose their instance in the settings and the translation option is only available when it is configured.

@connyduck
Copy link
Collaborator

connyduck commented Oct 28, 2022

Mastodon added a new api for translation, this will be the way to go
mastodon/mastodon#19218
We can detect the availabilty of the api via /api/v2/instance mastodon/mastodon#19434

@PJ-Finlay
Copy link
Author

Mastodon also now support LibreTranslate.

@nikclayton
Copy link
Contributor

It is also possible to do this on-device with https://developers.google.com/ml-kit/language/translation/android.

  • Translation is on-device, no content is sent to a third party (LibreTranslate, DeepL, etc)
  • Translation is presumably faster, and more reliable because of that
  • Translation works offline

There are a couple of caveats:

This is OK for me -- I'm imagining that translation would first need to be enabled by a preference (which would default to "off") and the preference screen can include the relevant privacy notices, so the user is making a fully informed decision about whether to opt in or not.

And this is still more privacy preserving than any method that uses LibreTranslate, DeepL, etc (i.e., the Mastodon API approach).

Thoughts?

@connyduck
Copy link
Collaborator

My preferred approach is to implement translation via the Mastodon api, but a fallback if that is not available would be nice.

Free ads for Google only over my dead body.
But there is Intent.ACTION_TRANSLATE https://developer.android.com/reference/android/content/Intent#ACTION_TRANSLATE which seems to be a nice option as well? There may even be open source translation apps that implement it.

@nikclayton
Copy link
Contributor

My preferred approach is to implement translation via the Mastodon api, but a fallback if that is not available would be nice.

I think it's definitely necessary. For example, the "translate" option on mastodon.social is currently returning a 503.

Free ads for Google only over my dead body.

OK, but integrating other services have similar disclosure requirements. For example, when translation does work on the web UI you get a "Translated from [language] using DeepL.com" message at the bottom of the translated status (https://www.deepl.com/pro-license/?&tab=pro, section 8.3.3)

As seen in this screenshot:

Integrating off-device services (e.g., DeepL, or LibreTranslate) in to Tusky also has an API key problem. These services need an API key to operate, and either:

  1. Tusky keeps that API key secret. In which case Tusky can't be built with F-Droid any more
  2. We expect users to go and sign up for a DeepL API key and enter it in to the app, or find/run a LibreTranslate instance themselves and enter the API key in to the app. Either of those options are a terrible customer UX.

But there is Intent.ACTION_TRANSLATE

That sends the text to another app (an additional privacy concern) and the translated text is not returned, the user views it in whichever app they have installed.

I think this also would be a significant usability problem -- imagine trying to translate a thread, you'd get bounced in and out of Tusky with every status you try and translate.

There's one other pro for doing language translation (or, at least, language detection) on the device as well. AIUI, the language tags on statuses are set by the posting user. I've seen reports that people aren't bothering to do this, and e.g., posting in German but leaving the post language set to English.

Because of this, the web UI doesn't offer an option to translate, because it thinks the text is already in English.

If we could do language detection on the device we could:

  1. Offer a translation option irrespective of what the status reports its language as being
  2. Prompt the user when they post a status -- try and detect the language the status is written in, and if it doesn't match the configured language prompt the user if they want to change it.

@connyduck
Copy link
Collaborator

#4307

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

6 participants