V2.2.0

[AlexDjSun]

Frontend is sending all data as strings, so POST /v2/correction accepts three keys - request which contains the original translation request data; response - the original translation text; correction - the user-corrected translation. A path to the file where all user-corrections are stored should be defined in config/confg.yaml in the parameter corrections_data_storage_path.

Example of saved data:

date: 27/02/2023 15:21:40

request: {"text":"Maailma","tgt":"eng","src":"est"}

originalTranslation: the World

correctedTranslation: of the World
---

date: 27/02/2023 15:25:40

request: {"text":"Aitäh!","tgt":"eng","src":"est"}

originalTranslation: Thank you!

correctedTranslation: Thanks!
---

[liisaratsep]

Let's release it as a beta version for now, keep this pull request open and iron out some details before merging. Some comments:

• the application header is not required for this endpoint
• variable naming should follow PEP8 conventions (lowercased, underscores allowed)
• Right now requests fail if the storage path directory is not created manually beforehand.
• for easier configuration with docker, the storage path should be configurable by environment variable (via BaseSettings not BaseModel), and let's configure it as a folder (not file path) and save data in separate files. I propose using {month}-{year}.txt or something similar which would guarantee that the file rotates every month which makes data exports easier
• the entire response should be saved - right now it only contains one field but the next development would add more information to translation request responses (for example how the request was split into sentences). This is actually more relevant to the frontend implementation.
• Allow the correction to be a string or a list of strings (just as in a translation request, the text can be either)
• I would also propose using a more standard data structure inside the files. For example have each entry as on json dict on one line which would just be the request body + timestamp info added to this dict. Let's try to minimize the parsing effort later on.

Question: Is the frontend really limited to sending previous request data as strings? If this is really the case, then we should have it be either a string or json as the json would be used in some other integrations in the future, but it would make a lot more sense not to use strings at all if we can and use types Request and Response in their schemas instead of str.

[liisaratsep]

This functionality has been moved to a separate component and will not be merged