Increasing the 'MaximumJobSize' in Translation Manager

Question

When sending a bundle that contains more than a hundred items for translation (to TMS), the translation job (on the Tridion side) is split into multiple translation jobs on the TMS side.

For example, if a bundle containing 280 components was sent for translation then there would be three matching jobs created in TMS:

• TMS job 1 - 100 tasks
• TMS job 2 - 100 tasks
• TMS job 3 - 80 tasks

This 'maximum job size' is configured within the %TRIDION_HOME%\config\TranslationManager.xml file:

<MaximumJobSize>100</MaximumJobSize>

Looking at the Configuring maximum job size page in the online documentation, one reason given for this is:

... Splitting the translation job up into sizeable chunks allows you to manage and process translations better and faster by scaling the job between several translators.

Q1. Given that each task (i.e. each individual Tridion component) can be assigned to a separate user (e.g. translator) in TMS (even if they're in the same TMS job), is this a valid reason?

Q2. Are there any drawbacks (performance, functional or otherwise) to setting the <MaximumJobSize> to a really large number (e.g. 2000) to prevent Tridion translation jobs from being split into multiple TMS jobs.

My client's concerns are that:

1. Splitting the translations into multiple TMS jobs increases the risk that one of these TMS jobs is missed/delayed - holding up the entire translation (on the Tridion side), and
2. That it may be unclear to the translator(s) that these tasks (e.g. all 280 of them) are related.

Answer 1

This limited mostly by how big of a request TMS API can handle. Translation Manager send all files in one request so if it is not split, at some point TMS API will fail with timeout or something.

Another consideration, is that with big amount of tasks in one job, TMS UI can become unwieldy for people who work on TMS side.

Also, if customer uses out-scaled Translation Manager, meaning multiple Translation Manager services connected to the same DB and working in parallel on sending and retrieving jobs. Sending job in one big piece may affect retrieving performance. Because one sub-part of a job can be processed only by one TM service at any time.

This means that if job is split in sub-parts, multiple services can retrieve different sub-parts at the same time, when if job is in one peace only one service can work on it. But this only apples for out-scale scenario.

In any case, in my opinion, 100 is very small number and it can be increased substantially before these problems occur.