Translate chat messages

[marcoambrosini]

☑️ Resolves

• Fix Translate chat messages [web frontend] #9528

Requisites

• Download nextcloud/translate and install according to Readme: https://github.com/nextcloud/translate
• If models are not downloaded with occ command, it could be done manually: https://github.com/nextcloud-releases/translate/releases/tag/v1.1.3 (and put in translate/models/ afterwards)

🖼️ Screenshots

🚧 Tasks

• Code review
• Visual check
• Handle rich content properly

🏁 Checklist

• ⛑️ Tests (unit and/or integration) are included or not required
• 📘 API documentation in docs/ has been updated or is not required
• 📗 User documentation in https://github.com/nextcloud/documentation/tree/master/user_manual/talk has been updated or is not required
• 🔖 Capability is added or not needed

[Antreesy]

So, i get a successful responce on axios.get(generateOcsUrl('/translation/languages')):
{"ocs":{"meta":{"status":"ok","statuscode":200,"message":"OK"},"data":{"languages":[{"from":"de","fromLabel":"German","to":"en","toLabel":"English"},{"from":"en","fromLabel":"English","to":"de","toLabel":"German"}],"languageDetection":true}}}

But when trying to translate with axios.post(generateOcsUrl('/translation/translate'), get an error:
{"ocs":{"meta":{"status":"failure","statuscode":400,"message":""},"data":{"message":"Unable to translate","from":"en"}}}

[nimishavijay]

I messed around a bit more with how this could look and I'd like to propose one more design change: use a border instead of a background color.

• Give --border-radius-large border radius to both the texts
• Use a --color-border border for the source text
• Use a --color-primary-element border for the target text
• use --color-main-background background for both the texts

what do you think? :)

[Antreesy]

what do you think? :)

Looks good and a bit less as Google Translate) Also user mentions are visible better now

[ShGKme]

Is the isTranslationAvailable always supposed to have value from capabilities?
If it is, maybe use capability instead of prop here? Or at least use capabilities as the default value. Then the long list of props to pass will be a little bit less 😀

[Antreesy]

Could be done later, when we'll finally reach Message refactoring =)

[ShGKme]

On the first modal open it always fails to me from the request in mounted:

Request:

fetch("https://<HOST>/ocs/v2.php/translation/translate", {
  "headers": {
    "accept": "application/json, text/plain, */*",
    "accept-language": "en-US,en;q=0.9,ru;q=0.8",
    "content-type": "application/json",
    "requesttoken": "<DELETED>",
    "sec-ch-ua": "\"Chromium\";v=\"112\", \"Not:A-Brand\";v=\"99\"",
    "sec-ch-ua-mobile": "?0",
    "sec-ch-ua-platform": "\"Windows\"",
    "sec-fetch-dest": "empty",
    "sec-fetch-mode": "cors",
    "sec-fetch-site": "same-origin"
  },
  "referrerPolicy": "no-referrer",
  "body": "{\"text\":\"Hallo!\",\"fromLanguage\":null,\"toLanguage\":\"en\"}",
  "method": "POST",
  "mode": "cors",
  "credentials": "include"
});

Response:

{"ocs":{"meta":{"status":"failure","statuscode":400,"message":""},"data":{"message":"Could not detect language"}}}

[Antreesy]

It's on API side then, we always send text and 'to' language

[ShGKme]

Yep, it seems, API is used correctly

[nickvergessen]

That's what I said in the office. You send a single word and fromLanguage is null.
But on a single word language models don't work and respond with a language, so we don't have a from when talking to translations provider and it returns with could not translate

[ShGKme]

Maybe we should not show the error message in this case?
Otherwise, all small messages show an error toast on opening the translation modal.
Also, if only one language is available, we can pre-select it.

[nickvergessen]

Well we could try to hide the error from empty runs yeah, but let's do that in a follow up