Documentation Center

Translation Flow and Integration Improvements

The Translation Job notion we introduced last release (10.0.x) has received improvements like relocalisation flow, an ability to export to the file system and a tight integration to SDL TMS,similar to the one we have for SDL WorldServer.

General

The requested languages field of a publication version will now automatically be updated by the service. The calculation is a union of the languages already set and the languages of the Translation Job where the publication was assigned to. Now you can immediately request a report in a send out language.

The Translation Job user interface was tweaked to reduce the number of clicks again. A new control for language/workflow selection with Select All and Deselect All, where we default to all selected. The Translation template drop down values now indicate for which system and alias they are. The Job Scope section allows you to select either Regular potentially re-exporting already send out items; or Only previously rejected translation items.

The rejected translation items flow - also known as relocalisation or retranslation - is a workflow extension on the typical flow: To be translated, In translation and Translated with Translation rejected back to In translation. The actual statuses are configurable as described in the requirements section for the integration. Any Translation Job set up for rejected translations will automatically send out source languages, forcing a full translation. [TS-8159]

The Translation Organizer service will during synchronization of the translation templates calculate which target languages should be shown in the Translation Job properties based on source language and translation template.

The Translation Organizer service relies heavy on the API layer of the parties it integrates. On the SDL LiveContent Architect side, we got a considerable performance boost by switching from the old-stack DocumentObj20 to the new-stack DocumentObj25 methods. This optimization boosts throughput of one service and makes it less likely that you need to scale out your services.

Generic Flow

Starting the translation process
  • The Technical Writer releases objects in SDL LiveContent Architect
  • A Translation Coordinator creates a translation job. He specifies the source and target languages, and he selects a translation template.
  • The Translation Coordinator adds publications and/or other items to the translation job.
  • When the job is sent to translation; the Translation Coordinator clicks the button Send to translation and the connector takes over, and it automatically:
    • Creates the target stubs in SDL LiveContent Architect for the objects you selected (Technically this is push translations orchestrated by Translation Builder service),
    • Extracts the content from the objects in SDL LiveContent Architect,
    • Moves the objects into In translation status, and
    • Creates the target project(s) and uploads the files.
Importing translated files

At regular intervals, the connector queries the translation system for all files that are translated and are ready to be imported in SDL LiveContent Architect; the connector does not wait until all files in a Translation Job are translated. Every task is imported separately.

The connector changes the status of the imported files to a Translated status so there is no need to do this manually anymore.

Limitations
  • Currently, a translation job cannot be restarted. You must create a new translation job so that you can track it separately.
  • You cannot send draft files for translation.
  • You cannot delete projects in translation management system. You can only cancel or complete projects. Project are automatically cancelled in the translation management system if the user cancels a translation job in SDL LiveContent Architect.

Server Artifacts

A Windows service named Trisoft InfoShare#!#installtool:PROJECTSUFFIX#!# TranslationBuilder One will be installed on every system. The service runs TranslationBuilder.exe that processes the initial workflow part of our Translation Jobs which mostly consists out of Push Translation Management follow-up.

A Windows service named Trisoft InfoShare#!#installtool:PROJECTSUFFIX#!# TranslationOrganizer One will be installed on every system. The service runs TranslationOrganizer.exe that processes the synchronization part among the repository and translation management systems.

Configuration of multiple translation management system instances

The TranslationOrganizer.exe.config general settings were moved to a general level, and we switched to TimeSpan based configuration, allowing more detailed configuration compared to older parameters like jobPollingIntervalInHours.

The configuration currently allows one instance for each <worldserver>, <filesystem> and <tms> configuration. Across multiple services and configurations the alias concept will assist you in the user interface. A typical configuration structure will look like:
<trisoft.infoShare.translationOrganizer>
<settings
  dumpFolder="#!#installtool:DATAPATH#!#\Data#!#installtool:PROJECTSUFFIX#!#\TranslationOrganizer\Temp"
  maxTranslationJobItemsUpdatedInOneCall="100"
  jobPollingInterval="00:05:00.000"
  pendingJobPollingInterval="00:15:00.000"
  systemTaskInterval="00:10:00.000"
  attemptsBeforeFailOnRetrieval="3"
  updateLeasedByPerNumberOfItems="100"
  synchronizeTemplates="true" />

<fileSystem>
  <instances>
    <add alias="" 
         externalJobMaxTotalUncompressedSizeBytes="5242880"
         exportFolder="#!#installtool:DATAPATH#!#\Data#!#installtool:PROJECTSUFFIX#!#\TranslationOrganizer\Export" />
  </instances>
</fileSystem>

<worldServer>
  <instances>
    <add alias=""
         uri=""
         userName=""
         password=""
         externalJobMaxTotalUncompressedSizeBytes="5242880"
         retriesOnTimeout="3">
      <mappings>
        <add trisoftLanguage="en" worldServerLocaleId="1145"/>
        <add trisoftLanguage="nl" worldServerLocaleId="1147"/>
        [...]
      </mappings>
    </add>
  </instances>
</worldServer>

<tms>
  <instances>
    <add alias=""
         uri=""
         externalJobMaxTotalUncompressedSizeBytes="5242880"
         retriesOnTimeout="3">
      <mappings>
        <add tmsLanguage="AF" trisoftLanguage="af" />
        <add tmsLanguage="SQ" trisoftLanguage="sq" />
        [...]
      </mappings>
      <templates>
        <!-- Add templates here -->
        <!--<add templateId="<ConfigurationId>" templateName="<TemplateName>" />-->
      </templates>
    </add>
  </instances>
</tms>
</trisoft.infoShare.translationOrganizer>

To allow the service to do a synchronization on the translation templates we introduced an API function TranslationTemplate25.DeleteByTypeAndAlias and a general setting in the configuration file to completely disable this feature @synchronizeTemplates.

SDL TMS

We allow configuring the export of extra metadata part of the .MET files which will be submitted to SDL TMS. This is configured through a section like:
<requestedMetadata>
  <ishfields>
  	<ishfield name="FCOMMENTS" level="lng" />
  	<ishfield name="FCHANGES" level="version" />
  </ishfields>
</requestedMetadata>
To allow grouping by metadata in SDL TMS (similar to ContentCollector), we allow the following configuration for job name creation. This is a limited historical functionality that will result in job names like <JobName>~<MetadataField1>~<MetadataField2>~...~<MetadataFieldN> [<UserName>] and smart truncation to 50 chars.
<groupingMetadata>
  <ishfields>
  	<ishfield name="FCHANGES" level="version" ishvaluetype="value" />
  </ishfields>
</groupingMetadata>

File System

The user experience has improved for creating and exporting translation jobs; the number of clicks needed to export translation packages has been greatly reduced. Where users had to use the Translation Statistics Report to export files and had to repeat this process for every language, they now can create a Translation Job and select a number of languages all at once. Once the Translation Job is created, users can export the files that need to be translated to the file system of the SDL LiveContent Architect server.

The resulting .ZIP file contains a sub folder per target language. [TS-7623]

We allow configuring the export of extra metadata part of the .MET files to the file system. This is configured through a section like:
<requestedMetadata>
  <ishfields>
  	<ishfield name="FCOMMENTS" level="lng" />
  	<ishfield name="FCHANGES" level="version" />
  </ishfields>
</requestedMetadata>

SDL WorldServer

You can map language-locale pairs. This is needed because in SDL LiveContent Architect you may have 2-digit codes whereas SDL WorldServer codes such as fr-fr are used.

SDL WorldServer archives its project information on a (configurable) scheduled basis (e.g. 15-30 days), several customers do this every 1-2 days. This could mean that at some point the connector tries to retrieve a completed project that no longer exists. The connector will check for step TRANSLATED CONTENT RETRIEVAL. This is now handled as a cancel. [TS-4667]

SDL WorldServer locales can now easily be retrieved by triggering a new command line option on TranslationOrganizer called --checkworldserver. For your convenience this can be simply triggered by executing StartCheckWorldServer.bat which will also verify your connection parameters specified in your .config file. [TS-6317]

Translation Templates with pipe (|) will synchronized and renamed to double hyphen (--) to avoid user interface problems. So a template named T | E | S | T will now show up as one valid value looking like T -- E -- S -- T. [TS-6910]

The SDL WorldServer connector only accepts files in the source language; it does not support pre-translated files from SDL LiveContent Architect.