XML for translation less efficient than Word?

[seanb_us@yahoo.com]

I have long heard and long been told that using structured FrameMaker would reduce translation costs, in part by removing a DTP component, but also because the XML worked (somehow) well with translation memory software.

We currently send Word and FrameMaker binary files to SDL for translation.

I reached out to SDL to ask about the benefits of XML from FrameMaker, instead, and they said Word files are best, and then FrameMaker binaries, and that XML was less useful. SDL does a lot of translation, so I was surprised to have my preconceived notions rocked this way.

Thoughts?

Cheers,

Sean

[Ian Proudfoot]

Sean,

I find that to be a very strange and hard to understand response. I've worked with a major US based translation agency on and off for the last ten years. I implemented and XML workflow for a major client where the master documents are XML and the authoring and publishing is using structured FrameMaker.

The benefits of this system are that the XML handling translation memory system was set up and barely changed for ten years. In that time we moved from FrameMaker 8 to FrameMaker 12. The change of FM version had no impact on the translation workflow because the XML output was identical from all FM versions.

I believe that the issue may be with perceived knowledge of XML when compared to Word or FrameMaker native files. XML can be scary to the new user...

However that's just hiding the problem as we all know that Word documents can be of wildly differing quality even if they look good on the surface. The same can also be true to a lesser extent with unstructured FrameMaker.

A lot of my time as a document architect and XML developer is spent creating systems that can handle the randomness of unstructured content. Perhaps SDL is translating the content but retaining the 'free-form' inventiveness of the source documents...

Ian

[Matt-Tech Comm Tools]

Agreed. Either the question or the answer were misinterpreted. XML is only a few percentage points of code vs. MIF or binary formats. This makes it easier to directly hand translate or machine translate, and over time increases the effectiveness of machine translation.

Ask them to elaborate on their response!

-Matt

[Stefan Gentz]

I can only second Ian and Matt.

I guess it also depends very much on who you talk to at SDL. There are a lot of people at SDL who understand XML very well and will tell you the exact contrary of what your contact told you.

Also, it depends often on if you are talking to a "project manager" or a "language engineer". The language engineers will tell you as well that XML is the best for translation. And: I have never met a senior project manager working for an LSP, who told me that Word is his preferred choice. In the contrary: I have never met a senior pm with experience who does not hate Word files in translation processes …

Of course, not all XML is good XML. I have also seen stuff like this arriving at an LSP for translation:

<root>
     <element1 content="translate me" />
     <element2 translate="translate me" />
     <element3 iforgotwhichatrributeihaddefined="translate me" />
     <element4 maybethisone="translate me" />
</root>

Such XML is, of course, no fun for an LSP as it makes a lot of work to create a custom filter for that.

But if you have a proper XML structure based on a DTD or Schema or a standard compliant XML like DITA, for which tools like SDL Trados Studio have predefined filters, then XML is definitively the way to go. And it's definitively the most stable process compared to any other file format.

[seanb_us@yahoo.com]

Hi,

Well, maybe. But, I won't have translation efficiency as a benefit to list when pushing going structured. Actually, this helps the move-to-Word cause.

Cheers,

Sean

[Jeff_Coatsworth]

@seanb_us@yahoo.com - huh?? Of course you'd have translation efficiency as a benefit using XML instead of Word. Much easier to compare XML text strings in the translation memory. I agree with Matt - you need to have them explain why XML doesn't work for them.

[seanb_us@yahoo.com]

So, I don't know enough about doing the work of translation to know what to ask. I figured asking if providing DITA XML would save costs over FM or DOCX files, and the answer was no, Word binaries are best. I don't know what specific questions to ask that would cause them to change their opinion. Does that make sense? Cheers.

[Russ Ward]

For me, I really don't know much more than what I shared, unfortunately. I have not dealt with translation for a while and never really that much to begin with. Maybe just start asking some other vendors. They love to talk. So much, in fact, maybe call from a pay phone and set up a temporary gmail account for it.

Like the 20th century pay phone reference?

Russ

[Matt-Tech Comm Tools]

Test it for yourself...Create a DITA topic in Fm, and save as both DITA and as MIF.

Open both in a text editor and ask yourself/your tx company which would be easier to localize.

For this discussion, MIF of a simple DITA topic is equivalent in complexity to the MIF of an unstruct doc.

-Matt

[Russ Ward]

Here is a modestly opposing viewpoint. Some years ago, I had some material translated by a large, well-known vendor. As an all-structured-all-the-time shop, naturally I thought to submit XML. They were unimpressed and wanted the FM binaries instead, explaining that they had well-established tools for content extraction and reinsertion that worked well with the binaries. I perceived that maybe the XML markup would just add complexity to the process and also felt the explanation was valid.

I did get a bit suspicious when they charged us layout fees in a addition to basic translation costs. In XML and especially structured FM, the layout and formatting is automatic. I never felt that I got a good explanation for that. Somebody else explained that the vendors really make their money with the layout charges, that the translation fees are not profitable. I don't know how true any of that is but it would explain a desire for layout-intensive Word binaries above anything else.

One disclaimer... My structured files are not DITA, but they do validate against the DITA topic DTD. I should think that if you are using an OTS standard like DITA, there should be no hassle at all to process XML. I should also think that it would be the most convenient at all, as Stefan seems to suggest.

One other thing to just throw out there... translation is just one facet of the considerations with regard to structured content. You should be using structured content anyway, whether DITA or whatever, because it brings a wealth of other benefits. Unstructured content is decades-old technology and will leave you stuck in the 20th century, no matter what. Any qualified technical writer should be able to understand and implement it. I'd encourage you explore it further regardless of the translation question, because otherwise you are spending lots of time doing repetitious work that could be easily automated.

Russ

[seanb_us@yahoo.com]

Hi,

So, the layout costs that SDL charges aren't bad. And, I understand the idea that content *should* be structured because binaries are bad and so last century, etc. The trick, of course, is pointing to the savings, and here's one avenue of revenue recovery that I can no longer point to.

Cheers,

Sean

[seanb_us@yahoo.com]

I cannot test myself, because I am not there yet. Sean