DeepL implemtation

[dqwiki]

In support of #50, we will be using DeepL to actively translate user appeals from their native language to the native language of the reviewer. To do this, we need to implement the following:

Important

This is not to be implemented for end users because of potential abuse and the amount of system coding it would take to prevent the abuse.

Note

Support to be implemented with DeepLcom/deepl-php

• Enable per queue setting (on/off)
• Create URL that will process the translation and redirect
• Allow users to set a user preference to the language they wish to translate to
• Require users set a user preference to the target language (Reason: Prevent translation into multiple languages per user
• Cache translations in database so that they aren't ran a second time if they are in the same language
• ⚠️ Prevent translation of admin comments, as they should be using the queue source language
• Log each use of the translation request API, but do not show it in the admin interface
• Possible future implementation: Setup sysadmin view to review the log of requests for translation so they don't have to dig the database
• Possible future implementation: Allow users to submit their own API key if they wish to go over the system limits (though I don't see us even hitting it right now
• Possible future implementation: Allow outbound translations of messages to end users

Note

We will not be translating the interface through DeepL, just user-inputted text fields from appeals.
There were 236427 characters in appeals in 2023 - considering the potential expansion of UTRS, and the fact that we could be translating into 2 languages per segment - we are looking about 1 million per year

SQL

SELECT 
    SUM(LENGTH(appealfor)) AS character_count 
FROM 
    beta.appeals 
WHERE 
    appealfor IS NOT NULL
    AND submitted like '2023-%';