Currently, the contenttranslation list endpoint for the query action is used in 6 different cases:
- Inside SX/unified dashboard, to fetch the draft and published translations (in these requests the sectiontranslationsonly param is set).
- When a draft translation is continued on mobile, in order to fetch the translation corpora units (the translationid is passed as parameter in this case)
- Inside the translation lists of the CX (desktop) dashboard to fetch draft and published translations (where the type parameter is used)
- Inside the RecommendTool to fetch translations to be used as seeds (here the sourcelanguage and targetlanguage params are used)
- Inside desktop editor, during translation initialization, to fetch draft translation and check for conflicting translations if needed (here the sourcelanguage, targetlanguage and the sourcetitle are used as parameters)
- Inside desktop editor, during translation initialization, to fetch translation corpora units in case of continuing a draft translation (the translationid is passed as parameter in this case)
The contenttranslation list exposes several optional parameters and the results that are being returned in each request, depend on some combination of the given request parameters. These parameters are supposed to provide some versatility in this query action, but in fact the caller must be aware of the specific combination they need to provide, in order to fetch the translations for a specific scenario.
A very indicative example of this complexity is the case no. 5, where when a registered user sends a request with the "sourcetitle", "sourcelanguage" and "targetlanguage" params, the response may contain a draft translation (if such translation is found for the current user) or a conflicting translation. On the other hand, for the cases no. 2 and no. 6, where only the "translationid" parameter is passed to the request, a draft translation, the translation corpora units and the target categories are returned. These differences in the response payloads cannot be anticipated by an unsuspected caller, and thus there is no added versatility through the several exposed parameters.
Based on the above analysis, in order to provide a clearer interface for the identified usecases, and avoid the complexity of all the different combinations, this task proposes the introduction of a usecase parameter that will support the translation retrieval for each one of the 5 usecases presented above. For now, we can continue to support the old combinations too, for backward compatibility, if it's needed.
