Is there any way to reduce the execution time of translation jobs in Tridion Docs?

In Tridion Docs, performing translation jobs takes a very long time. Even for a simple topic, it takes at least 20 minutes to complete the translation job. So I'd like to ask why it takes so much time? Is there any way to shorten this duration? Thanks

emoji
Parents
  • Hi,

    Thanks for the extra information. I assume you had a look at the Events tab of this TranslationJob. Or perhaps by looking at Organize Space Event Monitor, looking at the timestamps you could answer the below questions.

    1. Is your worry the complete throughput time of this simple TranslationJob is 20 minutes? The system is asynchronous and depending on load on the server, polling rates, other jobs... it can take 20 minutes before your request is head of the queue.
    2. Is your worry that once the TranslationJob is picked up the asynchronous Translation Organizer service it still take 20 minutes of calculation/CPU time? This is not about queue waiting times, but there might be something special with your xml content that causes the software to need 20 minutes. Sounds unlikely, if so, then please log a support request.

    As a reminder

    • TranslationBuilder Windows service polls for TranslationJob in status "ReadyForTranslation" and in turn takes care of generating the necessary target languages. It triggers and monitor a push translation for you. Once the target languages are created, it moves the status of the TranslationJob.
    • TranslationOrganizer polls for TranslationJob in status "Resolved" and takes care of the exporting/importing integration towards translation management systems

    Flowchart showing Translation Builder and Translation Organizer processes, including statuses like ReadyForTranslation, Expanding, Calculating, Resolving, Resolved, Sending, InTranslation, RetrievingTranslation, and Completed.

    Regarding scenario 1, then it is about polling times. So how often do services check for new incoming TranslationJob work. The system defaults are good for Enterprise production systems, but sometimes when people want to demo something then a default 15 minute poll cycle is considered "long". Note that polling too fast is a kind of load which also slows down the system throughput. Still, perhaps Translation Organizer common parameters or Application configuration for Translation Builder can inspire you more.

    If Infrastructure-as-Code is your thing, then have a look at our PowerShell module ISHDeploy, specifically cmdlet Set-ISHServiceTranslationBuilder and Set-ISHServiceTranslationOrganizer.

    Best wishes,
    Dave

    emoji


    Generated Image Alt-Text
    [edited by: RWS Community AI at 8:28 AM (GMT 1) on 27 Jun 2025]
Reply
  • Hi,

    Thanks for the extra information. I assume you had a look at the Events tab of this TranslationJob. Or perhaps by looking at Organize Space Event Monitor, looking at the timestamps you could answer the below questions.

    1. Is your worry the complete throughput time of this simple TranslationJob is 20 minutes? The system is asynchronous and depending on load on the server, polling rates, other jobs... it can take 20 minutes before your request is head of the queue.
    2. Is your worry that once the TranslationJob is picked up the asynchronous Translation Organizer service it still take 20 minutes of calculation/CPU time? This is not about queue waiting times, but there might be something special with your xml content that causes the software to need 20 minutes. Sounds unlikely, if so, then please log a support request.

    As a reminder

    • TranslationBuilder Windows service polls for TranslationJob in status "ReadyForTranslation" and in turn takes care of generating the necessary target languages. It triggers and monitor a push translation for you. Once the target languages are created, it moves the status of the TranslationJob.
    • TranslationOrganizer polls for TranslationJob in status "Resolved" and takes care of the exporting/importing integration towards translation management systems

    Flowchart showing Translation Builder and Translation Organizer processes, including statuses like ReadyForTranslation, Expanding, Calculating, Resolving, Resolved, Sending, InTranslation, RetrievingTranslation, and Completed.

    Regarding scenario 1, then it is about polling times. So how often do services check for new incoming TranslationJob work. The system defaults are good for Enterprise production systems, but sometimes when people want to demo something then a default 15 minute poll cycle is considered "long". Note that polling too fast is a kind of load which also slows down the system throughput. Still, perhaps Translation Organizer common parameters or Application configuration for Translation Builder can inspire you more.

    If Infrastructure-as-Code is your thing, then have a look at our PowerShell module ISHDeploy, specifically cmdlet Set-ISHServiceTranslationBuilder and Set-ISHServiceTranslationOrganizer.

    Best wishes,
    Dave

    emoji


    Generated Image Alt-Text
    [edited by: RWS Community AI at 8:28 AM (GMT 1) on 27 Jun 2025]
Children
No Data