The last few years have seen some chatter around the topic of “lights-out project management” which is an idea referring to the automation of tasks, particularly through the use of AI (Artificial Intelligence), so that human intervention is not required.  Ideally, of course, allowing project managers to concentrate their efforts on other, more productive and value-added activities.  The goal of reducing the time spent on administrative tasks is nothing new and some attempts to achieve this can be more of a false economy because of the “hidden” technical restrictions under the hood of the tools used.

For example, a project manager preparing a multilingual project in SDL Trados Studio will need to manage the packages or SDLXLIFF files for each target language, meticulously ensuring that the files for each language are identified and sent out to the right translators for each language.  If you have 40 target languages this can be quite a task.  So it’s no surprise that some project managers will look for a shortcut such as sending out the SDLXLIFF files from the source language folder as opposed to the target language folders to avoid the need for sending out different files from different folders to each of the translators involved.  But this is fraught with potential problems, not only due to the use of the source SDLXLIFF:

• source SDLXLIFF files have no target languages set so the tool handling the files and adding languages must be sure to add language codes that Trados Studio can understand
• source SDLXLIFF files are not fully segmented, so the CAT tools used to complete the segmentation need to be able to do this in the correct way for Studio to be able to understand the files when they come back
• not all CAT tools know how to create XLIFF files with the appropriate markup
• when you work with the SDLXLIFF files alone the management of this process requires some diligence because you have no visibility into the progress of the files, what’s been sent or what’s come back
• not all CAT tools can even handle SDLXLIFF files correctly in the first place

There may be more I’ve not listed here, but this should provide an indication of the sort of problems that could occur by managing this process in an un-managed way.  It’s in solving these sort of problems, which I think will be a godsend for many language service providers, where a new app called the XLIFF Manager plugin on the SDL AppStore comes into its own.  This new app is also a better replacement for the old SDLXLIFF to Legacy Converter (incidentally the same developer!) which allowed you to convert your SDLXLIFF files to the old TTX or Bilingual DOC formats so that you could share your Studio files with users working with other CAT tools.  These days XLIFF is a better file for interchange and the XLIFF 1.2 variant should be supported well by all CAT tools.

XLIFF Manager

So… how does it work and what does it do?  Quite simply it converts your SDLXLIFF bilingual files into a more generic and simplified XLIFF flavour so they can be handled elsewhere and manages the export/import process for you.

XLIFF support

The application currently supports two XLIFF variants:

1. XLIFF 1.2 SDL: this is the SDL AppStore Team take on the extensible XLIFF format taking advantage of the most important aspects of a vanilla XLIFF, supporting the all important MRK element and various attributes such as comments.
2. XLIFF 1.2 Polyglot: this provides support for the Google XLIFF format which is similar to XLIFF 1.2 SDL but there is no support for the MRK element.

In both cases the application really cleverly manages a model that removes all the complexity within an SDLXLIFF and makes it possible for the translatable content to be exported and then imported back in again after having been translated in an appropriate tool.  We already have plans to revisit this later this year and implement support for at least two more variants:

1. XLIFF 2.1 SDL: this will be the SDL AppStore Team take on the still extensible XLIFF format for those users who actually have a tool that can support XLIFF 2.1 in the first place.  Which of the eight optional modules we attempt to support I’m not sure… but we have some interesting ideas around this, so I’m also hoping for some feedback from you guys to keep it relevant!
2. SDLXLIFF: yes… we want to support SDLXLIFF simply because it would provide an opportunity to manage the process of sharing SDLXLIFF files outside of a package.  It happens now, probably at least as much as people share packages, so it seems to make sense to support this better.  Also interested in your comments!

Settings

Export

The settings for the application are uncomplicated, but are very important for covering options for segmentation and excluding content you don’t wish to send out for translation:

The default does not “Include Translations” and this means the project manager can pick a single XLIFF file from the export and use it for all the languages being translated for that file… the lazy XLIFF!  This is because it won’t contain the target element or the target language… for example:

Line #3: identifies the XLIFF variant (sdlxliff:support=”xliff12sdl”)

Line #13: does not contain the target language, it only contains the source language

Line #16 – #29 is the trans-unit element and there is no target element, only the source.

Line #20 – #25 is the segmentation information

The same file coming from an export to the Polyglot variant would look like this:

Significantly simpler, and shorter.  But it’s very important to understand the difference and make sure you export the XLIFF variant best suited for the tool it will be translated in.  Although the latter is designed for Google Polyglot this doesn’t mean you cannot use it somewhere else.  So make sure you understand where the file will be used and make the best choice for your needs… I’m looking forward to comments on this as well.

Import

The Import settings are similarly simple but with a few more settings that can be tweaked to ensure you import the content you’re looking for:

There are a couple of things to watch out for on the import.  First of all, if you are using the default export you need to see what target language code your chosen tool will use.  Trados Studio uses fully qualified language codes as you probably know if you belong to the club, so you could have problems importing the XLIFF files if the CAT used to translate the files added some strange variant of the language code you expected.  Fortunately the XLIFF Manager has a cool feature for managing this.  “Language Mappings” gives you the ability to specify what languages codes will be used by the translating tool and map them to the appropriate Trados Studio code:

If you exported your XLIFF by including the translations then you won’t have this problem because the target language will be included in the XLIFF… but then you’ll be sending specific files to each translator appropriate to the language they’re working into.  So the mapping table is a great feature.

Another thing to watch out for relates to this little understood feature in the XLIFF filetype for Studio:

I’m referring to number 1. which relates to the adding of segmentation information, and the MRK element, to the target segments.  If the translating CAT tool has this feature then be careful to note how it’s being used for the files.  It should be set up to match the requirements of the XLIFF you exported.  Number 2. is a useful feature which needs to be set to ensure that the target language element is populated in the XLIFF file.  Not all CAT tools will have these options, but it’s worth knowing about them as it may help you if you have any problems with the XLIFF files you’re working with.

Often I’ve been critical of the need for standards, but you can see why they are around because if you must work by transferring files around like this then having everyone work to the same standard removes many of the problems we see today.  But I guess the slow but sure transition to online working will gradually see the decline in these sort of workflows anyway.

XLIFF Manager Interface

I’m not going to spend a lot of time on this, but the interface is based around a new View in Studio like this:

It’s very compact and useful, with an amazing number of features:

• a searchable navigation view that groups your projects together by customer
• a management view listing all the files by language and identifying whether the files have been exported or imported yet
• ability to view a report that matches the one created in the Reports View in Studio for the relevant statistics associated with exporting/importing files.  The link to the report in this view is so fast it’s fun to simply click it!
• an activity report for each file, with all date/times based on UTC irrespective of the timezone of the user.  This is to ensure all users work with the same times… very smart!
• right-click and open any folder to get at the XLIFF files you need
• and more….

I often write too much in these articles so I’ll stop here and instead record a quick.. ish demo of the happy flow so you can see how it works.  In the meantime, if you do install it I’d be interested in your feedback as we’re already collecting ideas and requirements for the next updates and have these so far:

• progress bars while waiting for the export/import. Useful for large projects
• support for tracked changes in the import
• add support for an XLIFF 2.1 export/import
• add support for an SDLXLIFF export (to help with the management of an SDLXLIFF file workflow outside of a package)
• considering an Excel export/import (if we can do this reliably)

XLIFF Manager Demo

This turned out to be a little longer than I initially intended, but I used three tools to handle the exported XLIFF files to demonstrate how well this XLIFF Manager works:

1. memsource
2. memoQ
3. SDL Trados Live (due for release next week… at the time of writing!)

With that, I hope you find the video interesting and useful and I’ll end here.

Duration: 31 mins 37 seconds