Trados Limitations and Textboxes

This week I've learned that I hate embedded and grouped text boxes in Word. Why do I hate them? Well, Trados apparently does not pick up text that are embedded in text boxes when you attempt to translate the file in a tagged word format. If you use Tag Editor it hides the text between formatting tags, and the text in the boxes are not editable. Solution, SDLX actually picks up the text for text boxes that are grouped, but it ignores embedded boxes. By the way, text in embedded boxes show up as live text, they don't get picked by SDLX, and there is no option to have it pick up or extract the text. Therefore, the best was is to try and copy and paste the text into a word file, ignoring the boxes and hoping you copied and pasted all the text correctly. So, if you must use Trados, be careful of the grouped and embedded text boxes, you'll be missing a few words if you don't.

Is XML easier to Translate?

I've always been a proponent of XML content. I think it's faster to get things translated, and with a CMS it alleviates unnecessary emails and creates a translation work flow. However, there are a couple of fundamental problems in XML construction that you should address before setting up a translation work flow. One common problem is using CDATA sections.

Problem:
It's a very bad idea to use CDATA sections to separate
database content from database structure if you want to translate this content. CDATA sections make it impossible for third party tools to parse/separate the text and tags/elements within the CDATA sections. CDATA sections are designed this way because they are explicitly used to hold text and tags to prevent parsing. This makes it almost impossible for third party tools like Translation Memory Systems (TRADOS/SDLX) to parse the text and tags within the CDATA sections. TRADOS/SDLX exposes the CDATA content for translation without further parsing. Therefore, you get all the tags as "real text".

Solution:
You should considers using name spaces instead by placing the database structure, XML into it's own name space and have the database content in a second name space (or have it without a name space). SDL TRADOS Snippet might be a more or less usable workaround here, but it limits the tags you can "hide", and text within CDATA sections that are not closed will be hidden as well.

I hope this helps those of you out there who use XML as a content editor, or are planning to send XML files for translation. It's always a good idea to communicate with you translation vendor, or potential translation vendor when they are bidding on your project. Work together on finding ways to solve potential structural problems within the XML file. You certainly don't want unnecessary content translated, and this will allow you to preempt any exporting problems you might face with deleted or missing tags when you want to publish your translated content.

How to Tango with Lingo

The ICD production room heats up every time there are files that are incompatible with SDLX™ or Trados™ . We have to find a work around, and it's usually more complicated or costly. Fortunately, the guys at MadCap Software™ decided to create Lingo that allows translation companies to work with files created by Flare™ and Blaze™ (MadCap's help file software). They were thinking ahead instead of waiting for SDLX or Trados to come up with a filter.

What it basically does is allow a translator to translate content from Flare into an SDLX environment without using SDLX. So you get the SDLX translation environment (left column source language segments/ right column target language segments) in Lingo, and it also allows you to create a translation memory for content reuse, and a TMX (Translation Memory eXchange) so you can import/export the file to SDLX or other translation tools. It also eliminates the problem of content transfer or extraction from a Madcap program into another software program. What it does not do is analyze the files for repeat content (saving you money), and build a memory from previously translated files.

One more thing, Lingo does not translate the content for you. Automated translations like Google translate are crappy and only work for very simple sentences or independent words. Technical terms and sentences with context value are usually inaccurate with automated translations. Therefore, if you are using Flare or Blaze, you can acquire Lingo, import the Flare or Blaze file, export your content as a TMX, and send the TMX file to the translation company. They'll analyze the file and translate the TMX. You get a translated TMX back, you import it in Lingo and you have a translated help file.

Well, thank you MadCap for thinking ahead, and reducing the stress for all of us in the translation and localization business.