In the interest of selecting the most qualified translator, we sometimes work with preferred vendors who do not work in the same technology that we typically work with. In our translation workflow, we use SDL Studio as our preferred translation technology and this has been our preferred software over the last 15 years. There are many “compatible” platforms available that work with SDL Studio files and Translation Memory and Termbase formats that are exchangeable. Most notably, our translators work with SDL Studio and a few work with Wordfast Pro, Déjà Vu, and MemoQ. Because Wordfast tends to be very popular with translators (it’s the only major platform that works on the Mac) and we have experience in working with this software, we’ll use Wordfast Pro as an example of looking at how the compatibility promise holds up in the real world.
The “Translation Software Compatibility” Promise
Often compatibility is part of the selling point of any CAT tool looking to gain support in the market. Wordfast Pro is considered compatible with Studio because it can open SDLXLIFF files. However, being able to convert files should not be confused with compatibility. With Wordfast Pro, it’s easy to open and work in Studio files by simply adding the SDLXLIFF file to a Project. Translation Memories can be imported using the TMX standard that has been around for 20 years. And Termbases can be imported using the Tab delimited text file format or a TBX (Termbase Exchange Format). This form of “conversion-ability” can be expected among most common platforms. However, there is more to working with translation files than simply being able to open them. We know this from an earlier post as well about the new XLIFF standard that standards alone don’t always guarantee a streamlined process.
The Workflow in Reality
We use comments to provide additional information about past translations or ask questions to the translator. However, Wordfast and other programs do not import these comments.
In working with different translation softwares, the one thing that becomes apparent is that there is no such thing as “fully compatible”. We typically prepare Studio files with a few comments whenever we find answers to queries that translators should know about. Sometimes we add comments that provide instructions on structural information and reference points. However, Wordfast does not seem to be able to convert these comments to notes and so this information literally gets lost in translation. If you are not aware of this, you could be spending a lot of time working with Wordfast translators before you find out that none of the information was shared. The only way to include comments is to manually add these in the Wordfast environment. This lack of compatibility with comments was experienced with other platforms as well. It’s our experience as well that translators don’t typically ask whether or not comments were added. Perhaps they typically don’t expect a lot of support in files that are prepared for translation or they are not aware of the comment feature. Whatever the case may be, if you are not in control over the conversion process as a project manager, you may not be sure whether or not everything is included.
Translation Memory matching values are also lost in conversion. In other words, it is not possible for Wordfast to read the segmentation match values that we get in SDL Studio. This has caused problems in the past where translators miss draft (fuzzy) segments because of the lack of visual reference. If you are simply sending out an SDLXLIFF file for the translator to convert, you may never know that a translator essentially will have to click through every segment and use the TM (automatic) Lookup feature to see whether or not a segment is a match or a partial match. While most partial matches may be clearly visible by looking at the translation compared to the source, a simple change as a number or removal of a small word that changes meaning may not get caught this way.
Where are the Gaps?
After working with Wordfast Pro for awhile in demo mode, it seems that the best way to prepare a document for Wordfast is to simply process the file directly using Wordfast instead of converting from an SDLXLIFF (Studio) file. You can then apply the Translation Memory within Wordfast and see the leverage statistics. Adding in comments is relatively easy as well. The only thing so far that seems to be very tedious is to lock segments. Wordfast has a great advanced filter, but so far, I have not been able to select all segments of a specific kind or search group and lock these all at once. I wouldn’t know what to do for many jobs if that option was not available in Studio.
Even between “compatible” translation software platforms, you’ll need to manage a lot of conversions while ensuring to maintain quality standards.
What’s challenging with either approach (converting Studio files in Wordfast or preparing directly in Wordfast) is when you are working with a translator and editor in mixed software scenarios. It’s apparent that Wordfast deals with format tags differently than Studio. And segmentation also can be different between these programs. If you want best of both worlds, you’ll want to prepare a file in Wordfast for the Wordfast user and then work with a Studio prepared file when you switch to the Studio user based on the issues highlighted before. The way to bridge that gap is to make use of the well-established Translation Memory eXchange (TMX) format. However, different processing methods for tags and segmentation causes mismatches. If you have a large file prepared and translated in Wordfast and you upload that to the TM for processing against a Studio prepared files, be prepared to spend quite some time fixing formatting tag mismatches and segmentation differences. This method also seems impossible if you are working with a translation that is highly contextual, and may contain “inconsistencies”. Studio does a great job seeking for Context Matches, but it’s unclear whether Studio recognizes context from TMX files generated from Wordfast Pro. Finally, when your editor delivers their changes, do you go back to the translator in Wordfast and have them make changes there (so that they work in their environment with their Termbase and TM) or do you ask them to comment on the changes and manually make these changes as a PM in the Studio file (or have the editor do this)?
A Roadmap for Compatibility?
You can’t evaluate each program and the level of compatibility, but what if we got to a point where software would be compatible to a point where each platform has the ability to:
- convert the Translation File, Translation Memory and Termbase (which most do);
- read segmentation statuses, the ability to update these statuses and return to original format;
- add comments and convert them to notes by segment or parts of a segment (depends on how the source file deals with comments);
- read whether a segment is locked or not;
- share segmentation rules (more predictable TM output between platforms);
- share quality standard settings.
Being able to share quality standards and apply these to different platforms may be a bit of a stretch to expect from competing companies. But just think of the possibilities for larger corporations working with different vendors, or LSPs working with a variety of highly qualified translators with different software to all be on the same page when it comes to quality. For now, we must always make sure that we keep on top of quality standards between software platforms in a manual way.
Shaping the conversion around Compatibility
Just because a program claims that it is compatible with Studio does not mean that it is actually useful. This becomes apparent when working with – in our case – SDL Studio files in another program. SDL has not done many favors to that effect by designating their own standard within the XLIFF standards. I’m sure some of the problems in compatibility of workflows is debit to SDL’s approach to file formats.
While Studio offers a lot of convenience, not every translator will (want to) adopt Studio. It should be expected that sometimes highly qualified translators require you to approach translation technology a bit differently. Many online conversations around compatibility seem to revolve around Language Service Providers “forcing” a particular program on their translators and subsequent outrage over the matter (this is a whole other conversation around employee vs. independent contractor so LSP beware). It should be understood that neither translator, nor LSP, can invest in every bit of technology. And as we’ve seen with Wordfast and other programs, compatibility doesn’t simply mean everything in the workflow aligns perfectly. There will be some breaks in the process and without knowing how the file responds in another platform, there is a greater chance for miscommunication that can hurt a project. As an industry, I don’t see this issue highlighted enough by software providers that are supposed to make it easier for translators to collaborate. Whether or not platforms will work more towards further compatibility, we should find ways to make sure that translators and Language Service Providers are aware of the challenges created by working with different platforms.
