Here is something that we dealt with extensively several years ago, but it must be time to review. Last week I received some files from a client (a long-time subscriber to the newsletter) that were a terrible mess, exactly the mess that I tried to avoid when I talked about processing XML files with embedded HTML in TEnTs (translation environment tools). Since that client did not want to pay for consulting services to make it better (shame on them), they now have to share it with everyone else:

Virtually every TEnT separates translatables from non-translatables. This makes a lot of sense: The non-translatable stuff needs to be protected from over-eager translators, who at the same time don't want to waste their time making decisions about whether something is translatable or not. To achieve that goal, the different tools use different filters for different file formats, and these typically are similar across different tools: office formats, DTP formats, and tagged formats (HTML, XML, etc.). However, sometimes you encounter files that follow more than one format. Imagine a Word file with an embedded Excel spreadsheet, or a PowerPoint file with an embedded Visio file. The problem of TEnTs is that once they make a "decision" for one filter, they stay with it. This in turn means that they will simply ignore embedded files in the above examples, and you will have to extract that file from the "container" file and translate it separately. All of this is really not too much of a problem (as long as you notice it and don't send back a file with a great deal of untranslated text).

However, there are some cases that are not nearly as clear-cut, and this is true when the "contained" content is not actually a file but just snippets that follow different format conventions, like so often with HTML that is embedded within XML. XML and HTML are siblings that both use <markup that is surrounded by less-than and greater-than symbols> to describe formatting (HTML) or content (XML). If HTML text and code is embedded within XML, these symbols are written as special characters (&lt; and &gt;) so the application that processes the files knows how to distinguish XML code from HTML code. TEnTs, not being stupid, also "think" that they know what to do with it: They decode the special characters into the "correct" forms: < and >. Unfortunately, they stop right there rather than hiding them from the view of the translator.

This is an actual example of an XML snippet with embedded HTML that I worked on last week:

<Text LanguageId="7">&lt;center&gt;&lt;font color=red size=3&gt;Thank you&lt;/font&gt; for your interest in our survey.&lt;br&gt;This window will now close.&lt;br&gt;&lt;input type="button" value=^f('cqhidCustomMessages')['5'].label()^ onClick="closewindow()"&gt;</Text>

You can see that the XML tags are enclosed with the typical <less-than and greater-than> tag markers and they will be recognized easily by your TEnT. The actual translatable text ("Thank you for your interest in our survey. This window will now close.") is full of HTML code encoded with the less-than and greater-than tag markers (&lt; and &gt;). Importing a file with this segment into an XML-enabled TEnT results in this:

<center><font color=red size=3>Thank you</font> for your interest in our survey.<br>This window will now close.<br><input type="button" value=^f('cqhidCustomMessages')['5'].label()^ onClick="closewindow()">

The XML codes are hidden (or write-protected). The encoded HTML codes have been turned into proper HTML codes, but they are not protected and can thus be easily corrupted. Aside from the danger of corruption, these are an incredible nuisance because a) you will have to understand them, b) you will have to translate around them, c) they will make spell-checking a nightmare, and d) they will pollute your translation memory to no end.

Let's deal with the good news first: Two tools, Idiom WorldServer and Trados, allow a post-filtering of already-processed data to catch and protect those codes. Since we probably don't have to worry much about Idiom anymore, here is how Trados does it: Trados TagEditor includes a utility (Tools> Plug-ins> Snippet Mark-up Plug-in) that allows you to post-process any non-native tags within an Excel (!) or XML file. No, it's not particularly user-friendly, but, yes, it's very powerful once you get the hang of it. Here's how it works once you have it set up: When you open an Excel or XML file in TagEditor that also contains other code, it asks you whether you would like to process the remaining code as well. If you agree, it processes the file again, closes it, and when you reopen it, all the ugly code is protected. You'll need a few trial-and-error runs to make it catch all the code, but it's time well invested.

The other TEnT vendors have yet to introduce comparable features, but until they do, here is a workaround: Open Word and select Tools> Options> General> Confirm conversion at Open (Word 2003 and earlier) or Office button> Word Options> Advanced> General> Confirm file format conversion on open (Word 2007). Open the XML file in Word and, when prompted, open it as an encoded text file and make sure that you select as the code page UTF-8 or whatever the original code page of the file was. The file will now be displayed as a plain text file. Now, depending on the tool that you are using, you can change the style or the formatting of both the XML and HTML tags so that they will be treated as external or internal tags once the file is saved to RTF.

For instance, with Across, Transit, and Déjà Vu you can open the Find and Replace dialog in Word (Ctrl+H), select More, check "Use wildcards," search for \<*\> and &lt;*&gt; and replace it with hidden text (select Format> Font> Hidden for that). After that, uncheck Use wildcards and replace &amp;nbsp; with hidden text.

For Wordfast, MemoQ, and SDLX, you can do the same, only in this case you can replace the same items with the Trados-style tw4winExternal and/or tw4winInternal. (If it is not listed in the list of available styles, copy and paste a couple of characters from another document with that style into your document -- it will then be listed -- and make sure to delete the characters once you have used the style.)

Once this is done (and I'm pretty sure you can find a style or format that your tool of choice recognizes as non-translatable text), save the file as an RTF file, import it into or open it with your TEnT, translate it, export or clean it, open it in Word, and save it as a text file. Make sure that you set the code page correctly and that the extension is .xml rather than .txt. (You can achieve that by placing quotation marks around the complete file name in the Save as dialog.)

Sound a bit involved? I agree, it does. The problem is that it is REALLY involved to translate files with tons and tons of non-protected formatting like the one I describe above. So I would rather spend the few minutes to prepare the file adequately in the project preparation phase rather than messing up code or being annoyed in the much longer translation phase.