Salesforce

WorldServer before version 11.8 - Segment Status set to "No Status" after import of translated XLIFF file and error 'Live translation memory was not updated for the following changed segments, because they were not assigned a translation status'

« Go Back

Information

 
Article TypeSolution Article
Scope/EnvironmentWorldServer 11.7.3 and earlier
Symptoms/Context
In my WorldServer environment with Live TM, the translation is performed in XLIFF format. The project is exported in XLIFF format and the XLIFF file is translated outside of WorldServer. The translated XLIFF file is then imported after translation.
During the import of the translated XLIFF file, I notice this error/alert:

Live translation memory was not updated for the following changed segments, because they were not assigned a translation status

User-added image


Note: the Task History will not report the issue.

After opening the file/Task in Browser Workbench after the import, I notice that the segments that were manually translated in the XLIFF file do not have the correct Segment Status. Instead of being in Pending Review or Reviewed status - as set in in the XLIFF file - the status is None. Moreover: the TM is not updated with the translation.

User-added image
Resolution
Starting from Version 11.8., the segment status of translated XLIFF files are recognized and hence the TM is updated and the issue is fixed. In earlier WorldServer versions, as explained in this article, XLIFF is not a supported export format in a WorldServer live TM environment. The WSXZ package format should be used.

To avoid encountering this issue in general, always export your Worldserver projects in WSXZ Studio package file format and work in Trados Studio 2019/2021/2022 only.

The XLIFF export format has many limitation:  it does not include any Translation Memory coming from WorldServer. Also no target file in original/native source file format can be created from Trados Studio to verify that there are no error or that the target file looks good

Moreover: no multiple TM export and penalties can be applied using XLIFF format. These and many more features related to the advanced integration between WorldServer and Trados Studio are not applied - which can affect the quality of the translated content. Therefore, we do not recommend to use XLIFF as an export format.

However, if you work in a live-TM WorldServer environment and on a version lower than 11.8, these are the possible workarounds:

Workaround #1 to prevent the issue to happen while using XLIFF format:

1- Change your Workflows to add a Set Translation Status Step after the Translate step. Configure this step to change only segments in None status to Pending Review

Note: this workaround works well for files with low or medium wordcount or segment number. It is quite expensive in terms of performance with very large file. 

Workaround #2: To fix the problem in the single affected tasks/files (if Workaround #1 is not applied or applicable):
  • Open the task in Browser Workbench
  • Change the segment view to "All except 100% and ICE Matches"
User-added image
 
  • Select all the segments that have been manually translated. You will recognize them by their green color.
  • After selecting all manually translated segments, click on the Tools button and select Translation Status/Pending Review or Translation Status/Review (depending on the status you want them to be in). 
  • Make sure the status has now indeed changed to Pending Review or Reviewed.
  • Click on Save to update your TM with the translation
Root Cause
In earlier versions of WorldServer (before 11.8. where the issue is fixed), XLIFF is an unsupported file format in a WorldServer live TM environment. 

The reason for this is that WorldServer does not recognize the segment status set in a XLIFF file by the tool used to translate it. As a consequence, after import the segment status is set to No Status and the TM is NOT updated. This has been filed as defect CRQ-3715 and fixed in version 11.8.
Reference
Attachment 1 
Attachment 2 
Attachment 3 
Attachment 4 
Attachment 5 

Powered by