Translation management improvements

Translation Manager, Translation Builder and Translation Organizer have been improved in this release.

New translation review flow

The translation flow has been upgraded to include a review step: rejecting translations no longer requires that you create a new job for submitting the rejected items again. The basic translation flow is now:
  • Send for translation.
  • Receive, then accept or reject the translated items.
  • The accepted ones are done, the rejected ones go back to translation and come back corrected.
  • The job can be closed when all items are accepted.

All documentation about the translation flow has been updated accordingly. Check out the Deprecated, obsolete... chapter of the Release Notes for details about compatibility.

Main changes:
  • New statuses (Translation in review, Translation rejected) and transitions have been added to the out-of-the-box set.
  • Translated has become Translation accepted. You need to rename this status manually if you want to use a translation system.
  • The interaction between Translation Organizer/Translation Builder and the external translation systems (WorldServer, TMS) have been adapted.

Translation flow made static

The out-of-the-box list of statuses and transitions for the translation is now the reference for all users. This provides a simple and firm basis for both users and system.

Main changes:
  • All the statuses and status transitions you need for a complete translation flow is out-of-the-box.
  • Statuses and transitions from the box are the recommended ones.
  • This reference flow can be changed/adapted: it requires a configuration operation.

Complete descriptions can be found in the full documentation.

Improved cancellation feature

Main changes:
  • Cancellation has a stable and consistent behavior whichever system you use for your translation: file system (internal), WorldServer (extenal), TMS (external).
  • A cancellation rolls the items back to To be translated.
  • New job statuses (CancellationRequested, SkippedSending, SkippedRetrieving, ItemsRollbackPending, ItemsRollback, ItemsRollbackFailed, JobRollbackPending, JobRollback, JobRollbackFailed) and transitions have been added to the out-of-the-box set.

Complete descriptions can be found in the full documentation.

Translation procedure simplification

In previous versions you needed to add Requested languages in the publication's version properties before you could create a translation report for these languages. You also needed to manually create the export file using the report.

Now when you create a translation job, the translation dialog lets you select the target languages whether or not the languages are part of the Requested languages in the properties, then the system automatically generates the export files and sends them. The system also updates the Requested languages list with any language you may have added to this translation job, this makes sure you can then generate a report for a current translation job.

Removed racing condition that sends out content twice

Regarding predictability, translations were requested by sending out translation jobs to the target translation systems. However, in some high volume scenarios some items were requested more than once which results in an increased translation cost. This happened when a content object is part of more than one translation job being prepared for sending out.

The correction is in avoiding the sending race condition. We do this by introducing a lease mechanism (visible in Settings > Default Settings area). Only one Translation Organizer instance can send out a job. Note that scaling out services Translation Builder and Translation Organizer still has benefits for the more often executed preparing, checking and retrieving translation actions.

Before: Parallel sending

Translation Builder grabs a job, breaks it down into topics and checks the status of each topic. If the status turns out to be In Translation, the topic is not passed over and will not be translated. Translation Organizer then sets the status of the topic to In Translation before sending it. There is a probability that a topic (Topic A in this example) is sent at the same time by both Translation Organizer instances.

After: Sequential sending

The status In Translation is checked again just before sending, and topics are sent one at a time. No more double sending.

Introducing an External Validation endpoint

The CMS contains your document types (DTDs and catalog) configuration, potentially including specializations. The new endpoint allows to single source that configuration by making them available over a REST endpoint. First use case is to allow SDL TMS and SDL WorldServer to validate xml-based translations before allowing retrieval to the CMS.

It is now possible to validate the XML against the DTD by using a newly created endpoint: the External Validate endpoint accessible at https://ish.example.com/ISHCM/Api/ExternalPreview/Validate with either a GET or a POST call. The endpoint will provide a detailed list of errors.

Improved polling increases throughput

Translation Organizer checks for pending jobs at regular intervals. The interval is configured through jobPollingInterval in TranslationOrganizer.config, the default value is 5 minutes. When a group of smaller jobs is available for processing, this interval could make the global processing longer than it should, as Translation Organizer waits for the end of the interval before it picks up the next job.

Now Translation Organizer automatically checks for an available job whenever a job has been completed, in addition to the regular check after the interval.

Stability improvements for the SDL TMS and SDL WorldServer integration

Whenever the server returns an http 500 error to Translation Organizer - which typically means that the remote system is severely disturbed - during the retrieval phase, the former behavior was to request the user to manually restart the job. Now Translation Organizer automatically retries the job.

Some transmission issues have also been fixed, such as the processing of Logical Identifiers having GUIDs with dots (.) as separators. An issue which was introduced on 2016/12.0.0.

Logging details have been added for a better follow-up of every step of the interaction between Translation Organizer and TMS or WorldServer.

Other improvements

  • Translation Organizer no longer returns all tasks together with the project when it ends, thus improving the performance.
  • We included the time in the database, taking the time zone into account. This allows for better time management by Translation Organizer.