[Feature Request] LibreTranslate integration

[PJ-Finlay]

https://github.com/uav4geo/LibreTranslate

[adeekshith]

Also see #134

[connyduck]

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]

@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]

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.

• https://libretranslate.de/
• https://translate.astian.org/

@pierotofy

[connyduck]

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]

Mastodon added a new api for translation, this will be the way to go https://github.com/mastodon/mastodon/pull/19218 We can detect the availabilty of the api via /api/v2/instance https://github.com/mastodon/mastodon/pull/19434

[PJ-Finlay]

Mastodon also now support LibreTranslate.

[nikclayton]

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:

• The option to start the translation must be labelled "Translate with Google", per https://cloud.google.com/translate/attribution#mobile_apps
• The translation results must have a "translated by Google" badge at the bottom. There are UI examples of this at https://cloud.google.com/translate/attribution#attribution_and_logos
• There must be a disclaimer in the app (e.g., in the preferences that enable this feature), https://cloud.google.com/translate/attribution#disclaimer
• Per https://developers.google.com/ml-kit/terms#privacy, content to be translated does not leave the device, but "The ML Kit APIs may contact Google servers from time to time in order to receive things like bug fixes, updated models and hardware accelerator compatibility information. The ML Kit APIs also send metrics about the performance and utilization of the APIs in your app to Google. [...] You are responsible for informing users of your app about Google’s processing of ML Kit metrics data as required by applicable law."

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]

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]

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]

https://github.com/tuskyapp/Tusky/pull/4307