If you translate5 something in

https://www.deepl.com

and then click on a word of the translation, DeepL offers alternative translations for this word.

The same we should implement in translate5 in the segment editor for a right click on a word based on proposals of the MT.

If the right click offers already proposals from languagetool because of a language tool error, the alternatives of the MT should be offered below in an own category.

What alternatives exist should be queried for all words of a segment, when the segment is opened.

This feature should be offered, if an MT is assigned to the task for which this feature is integrated.

In a first step it will be integrated for Textshuttle (as part of this issue).

The to be used api call of textshuttle is

(/alternatives/get_words) API-Dokumentation

In a second step (not part of this issue) this might be done for GPT.

Please see attached image, how this is solved in the UI.

Open questions:

The main question is, how we are able to deliver an acceptable usage performance for the translator / reviewer in the UI.

The following alternatives exist with their pros and cons:

Tunneling request through translate5's backend, when the user wants to see alternatives

The user would right-click on a word and then the request would be send to translate5's back-end and from there to the MT.

This would be possible to do with the current TextShuttles API and translate's textshuttle authentication. Yet the piping through the back-end of translate5 would probably add 0,5 to 1 sec more latency, which might be to slow for the user then.

Tunneling request through translate5's backend, when opening the segment

This would solve above described performance issues. Yet Textshuttle would have to calculate a lot of alternatives for the different possibilities and mark in its answer the words and phrases, that would be offering alternatives, so that translate5 knows, where alternatives start and end.

Also it would mean much for system load for textshuttle, because alternatives are requested and all possibilities calculated on each opening of a segment.

Calculating alternatives on pre-translation of a task

Textshuttle could calculate the alternatives during pre-translation. This would solve all performance issues - alternatives could be stored in translate5 and loaded in the front-end, when opening the task already. Regarding usability and user experience, this would be the best solution.

Yet Textshuttle would also (as in the previous option) have to calculate and mark possible alternatives, when doing the pre-translation. Which might slow down the pre-translation.

Direct request from the translate5 UI to TextShuttle

The request would be send directly from the translate5 UI to TextShuttle.

According to TextShuttle the performance would be fast enough for letting the user can click on a word to get alternatives (still the question would be, how fast it is).

The question is, how to authenticate the user at TextShuttle without a security risk.

Options here could be:

1. Encrypt the textshuttle api key once per session. translate5's server back-end would tell textshuttles api the key, that is needed to decrypt the token. There would still be the possibility of misusing the key, but it would be substantially reduced.
2. Textshuttle could offer an end-point to request a bearer token with a timeout of e.g. 15 min. translate5 would request for every user a new bearer token every 14 min, if a task is open, in which textShuttle should be used. There would still be the possibility of misusing the token, but it would also be substantially reduced.