Details
-
New Feature
-
Resolution: Unresolved
-
None
-
None
-
High
-
-
Empty show more show less
Description
problem
The InstantTranslate filepretranslateAction API endpoint is receiving data, starting the whole import workers and is ending it self. The ready translated data can then be fetched later.
For a specific use case with very small data (given as fileData and fileName POST parameter) this taken to much resources since the client is making multiple polls to check if the task is ready. Also the client wants really fast results, so the seconds between the poll calls must be removed.
solution
We provide a separate endpoint in Editor_InstanttranslateapiController, which does basically the same as the filepretranslateAction, with the difference that it directly returns the results of the translated task (connection stays open for the call that uploads the file for translation and returns the translated file, once it is ready).
Should be a separate endpoint (and not just a parameter in the existing one) in order to control access burst restrictions in nginx for that endpoint.
The response of the new endpoint should contain the id of the created task, so that it can e. g. be deleted with another request via api.
Attachments
Issue Links
- blocks
-
TRANSLATE-3647 Okapi integration: Enable down- and upload of fprm and pln files and pre-parsing of xliff by Okapi
- In Progress
- is blocked by
-
TRANSLATE-4093 OKAPI integration: Compatibility with 1.4.7, clean up Pipelines
- Final pull request