Salesforce

WorldServer - About the content of WorldServer WSXZ packages exported after segmenting assets using the old Idiom Legacy filters

« Go Back

Information

 
TitleWorldServer - About the content of WorldServer WSXZ packages exported after segmenting assets using the old Idiom Legacy filters
URL Name000008597
SummaryWhen files are segmented using Idiom Legacy filters are exported to a Studio package (WSXZ), you should be aware that the content of that WSXZ package is different than the content of a Studio WSXZ package exported from files segmented with Studio File Types. It is very important that translators working with Idiom Legacy filter WSXZ packages really work only with the original package and not apply other workarounds like working with the SDLXLIFF file only, or creating a target XLF file out of the SDLXLIFF file and open it separately. This type of workarounds might cause corruptions and might prevent the creation of a correct WorldServer Return package, resulting in errors when importing back to WorldServer. 
Scope/EnvironmentWorldServer
Question
What should we be aware of when working with WorldServer WSXZ packages exported after segmenting assets using the old Idiom Legacy filters? What are the differences between WSXZ packages coming from projects segmented with Studio File Types and WSXZ packages coming from projects segmented with Idiom Legacy filters?
Answer

Some customers are still working with Idiom Legacy filters for segmenting their files. Examples of such filters are:

XML (NT) Filter
DOC Filter

Excel Filter
Office 2007 Filter

HTML (NT) Filter 
JavaScript Filter
JSP/ASP Filter
MIF Filter
PPT Filter
RTF Filter
Text Filter
XSL Filter
SGML Filter


These filters are not visible in new installation of WorldServer (installed after WorldServer 10.4.x), but you can still find them in WorldServer environments that have been upgraded from older versions where these filters were in use. These filters are usually marked as Deprecated and are officially no longer supported. We recommend that our customers migrate all their file formats to Studio File Type filters.

However, some customers still use these filters to segment their files. When files segmented using Idiom Legacy filters are exported to a Studio package (WSXZ), you should be aware that the content of that WSXZ package is different from the content of a Studio WSXZ package exported from files segmented with Studio File Types.

This article explains what a WSXZ package usually contains, assuming it comes from a project that uses Studio File Types to segment the project's source files:

WorldServer - What is included in WorldServer Export and in a WorldServer Return Package?

The main differences between a Studio File Type WSXZ package and a Legacy filter WSXZ package are:

1- the Studio File type WSXZ package will always contain the bilingual file in *.SDLXLIFF format. The *.SDLXLIFF file name will also always include the original source file format file extension and part of the file name (if the file name is too long, it will be truncated) and it might also include some random numbers to make the *.sdlxliff file unique. As an example, the bilingual file inside a WSXZ package exported from a source XLSX file with the file name Sonderthemen.xlsx will be called Sonderthemen_xlsx.sdlxliff. The content of such a WSXZ package could look like this:

User-added image

If you open such a WSXZ package in Trados Studio, Studio will open the SDLXLIFF file as it is. If you save the SDLXLIFF file as a target, it will create the target file in its original format, i.e. XLSX.  The WorldServer Return package created in Studio will contain only the translated SDLXLIFF file with the very same name.

2- A WSXZ package exported from a project or Task segmented with Legacy filters - on the other hand - will always contain an XLF file with the naming convention filename_tasks.xlf.
Note: The file name makes no reference to the actual source file formatThe content of such an export WSXZ package could look like this:

User-added image

When opening such a WSXZ package in Trados Studio, Studio uses a specific WorldServer Converter to temporarely convert the XLF file to an SDLXLIFF format. The resulting SDLXLIFF file will have the file extension *.xlf.sdlxliff. Basically, Studio converts the XLF file to an SDLXLIFF file. If you create a target file in Studio out of the SDLXLIFF file from the WorldServer project, you will always create a bilingual XLF file. Therefore, with such Legacy filter packages, you will not be able to check what the target file really looks like in its original format. This is one of the limitations of using the Legacy filters instead of the Studio File Types filters.

Also, when such a WSXZ package and the project's file is opened in Studio, the segment numbers will not be chronological: this is also specific to bilingual files segmented with Legacy filters. Here is an example where you can see that the numbering "jumps" from 2 to 4 to 6 etc.:

User-added image

If the segments included in the package contain tags/placeholders, after opening the package in Studio, those placeholders will display automatically similarly to how they display in  Browser Workbench, for example {1}, {2}, {3}, {4} etc. Here is an example:

User-added image

However, this is just a Studio View setting. Use the Tag Options section in Trados Studio and set the View to Full Tag view here:

User-added image

Once you have done that, you will be able to see the content of the tags, as in this example:

User-added image

One last, but very important point: Studio Return packages created out of WSXZ packages from files segmented with Idiom Legacy filters will always contain an XLF file called Studio_tasks.xlf. 

Trados Studio 
will convert the SDLXLIFF file previously converted from the XLF file in the export package back to XLF and will always give it the name Studio_tasks.xlf. The actual target file after translation can only be viewed in WorldServer after the import of the Return package.

It is very important that translators working with Idiom Legacy filter WSXZ packages really work only with the original package and not apply other workarounds like working with the SDLXLIFF file only, or creating a target XLF file out of the SDLXLIFF file and opening it separately. This type of workaround might cause corruption and might prevent the creation of a correct WorldServer Return package, resulting in errors when importing back to WorldServer. 

Reference
Attachment 1 
Attachment 2 
Attachment 3 
Attachment 4 
Attachment 5 

Powered by