How can a structured frame be used for translating books to foreign languages?

Report · May 27, 2011

I keep reading about how a structured approach can improve the translation process (from english to foreign languages), however, i can't seem to find specifics about a particular method or tutorials about how to go about it (specifically). My question is, how (specifically) can structured framemaker be used for translation from english to foreign languages? Links to tutorials on this issue would be greatly appreciated. Thank you.

Report · May 28, 2011

Jeff,

It seems to me you misunderstood some of the (certainly abbreviated) discussion.

I try to summarize very short: »Structured documents« in FrameMaker are based on a DTD or XML Schema which defines the names and order of elements and attributes, which are then used to structure your content. Those definitions are format-free by design. So for usage in FrameMaker you create an EDD (Enhanced Definition Document?) that adds formatting rules to all those elements.

The effort you invest once into the design of those formatting rules is saved later many times, because writers non longer do the formatting. As such they also cannot introduce »private formatting«. After translation of format-based (sometimes called »unstructured«) documents someone usually has to do some DTP work, for every language. If the EDD is well-designed and does all required formatting automatically, those efforts can be saved.

- Michael

Report · May 31, 2011

Michael,

As you suggest, I had thought that DTP work could be alleviated and therefore costs reduced, using structured documents or even just XML. Recently, though, we had some translations done of structured documents and the original quote included all the DTP charges. I inquired about this, saying that I thought structured Frame effectively formats itself. The vendor replied (paraphrased) "Sometimes structured documents are even more work, as we have to merge the translated content with the original markup, not just do the formatting." So not knowing any better, we just paid it.

Do you think we got snookered? I know that translation vendors make a lot of their money with DTP charges, so I can see an incentive to preserve them. It doesn't seem quite right, though, that well-structured documents would present a situation where more work was required, instead of less. The structure of these files is even valid against the DITA topic DTD, so I would think that there would be some kind of standard framework most vendors would already have in place for migrating content from our files to their system, and back again.

Russ

Report · May 31, 2011

Russ,

Although I have been involved in very little translation work, I believe you got snookered.

Several years ago, I attended a small forum on using XML in technical writing. It was about the time that Microsoft Word switched to an XML-based file format. One of the speakers was an owner of a small translations company. He was all gaga about the fact that a Word file could be saved as XML. He stated that his translations house would prefer content in XML, because it removed all the formatting leaving only the content to manage. We have not used him to translate XML documents, so I cannot state if there are any savings from the DTP costs. If one has a well-running XML roundtripping workflow, I would think one could hand off the XML files to the translations house and get translated XML in return...no DTP required; you do the DTP yourself when you bring the XML into FrameMaker.

Two years ago, we asked one of our employees from Columbia to translate a 250 page, structured FrameMaker user manual into Spanish. The employee had never used FrameMaker, structured nor unstructured. I gave her about 10 minutes training. She a very, very good job. I can't remember if I had to fix anything, but if I did, it was very little. Our EDD inserts a few test snippets automatically, such as Warning, Caution, etc, in addition to autonumbering text, such as Figure and Table. She gave me the Spanish for these snippets. I then added formatting rules to the EDD that were triggered by a book attribute for the language. After importing the updated EDD, all these snippets updated correctly.

So, my little experience is that a well-designed EDD should virtually eliminate the DTP that a translations house needs to do; the only thing I can think of is fixing pagination. Moreover, an XML workflow should eliminate the DTP cost entirely.

One could always ask the translations house to do ONLY the translations, and let you do the DTP yourself.

Van

Report · Jun 06, 2011

It could be my problem, but I have never seen a translation for delivery as PDF that did not require some DTP, for a number of reasons, one of the least known being typographic rules.

These are perhaps not terribly relevant when producing internal documentation (but you do not normally need to translate internal documentation anyway). However, contravening the target language typography (in the sense of 'arrangement and style treatment of all the elements on a page') will make your publication look amateurish (and therefore devalue your service) if you have to produce, say, a user guide or an annual report in PDF format.

For example (I could give you dozens of examples), in my native European Spanish, as in other European languages, the following must be avoided:

Four or more consecutive lines must not begin with the same letter.
Three or more consecutive lines must not begin with the same syllable.
Two or more consecutive lines must not begin with the same word.

How can translators comply with this and similar rules if you give them XML files, which by themselves include no instructions about how to display the content? They cannot.

Should they apply your stylesheet to their translations and then DTP the outcome in order to make it compliant with the typography of the target language? In this case, any subsequent changes made to the original XML documents would result in further DTP costs, which somehow contravenes the philosophy of utilising a common information database to interchange data and handle publications.

I always wondered whether DTP would still be necessary if different stylesheets (or EDDs) could be built, each one containing (should this be feasible) all the typographic instructions that are necessary for a specific language (or rather "audience," as typographic rules may actually vary from a region—e.g. France—to another—e.g. Quebec—within the same language).

Van, please, did your snippets and formatting rules also fix the typography (things like the 'must-not-begin' rule I mentioned above) of your target language documents?

Jesús

Report · Jun 06, 2011

Jesús,

I always wondered whether DTP would still be necessary if different stylesheets (or EDDs) could be built, each one containing (should this be feasible) all the typographic instructions that are necessary for a specific language (or rather "audience," as typographic rules may actually vary from a region—e.g. France—to another—e.g. Quebec—within the same language).
Van, please, did your snippets and formatting rules also fix the typography (things like the 'must-not-begin' rule I mentioned above) of your target language documents?

The snippets had nothing to do with what you call typography rules. They were the words "Figure" and "Table" that were part of the autonumbering for figures and tables. There were snippets in the cross-reference formats, such as "See ... on page ..." So, they had virtually no impact on altering any typography issues.

I have written and continue to maintain a rather large EDD. There is no way that an EDD can be written to enforce the typography rules that you mention. Line-breaking is not controlled by the EDD. You are correct that one must do some DTP to enforce such rules.

Van

Report · Jun 06, 2011

Note that most (if not all) of these DTP tasks can be automated using an FDK client, or FrameScript, or now with FM10 ExtendScript. If you can accurately describe what to look for and how to fix it, it can probably be automated. I've created a number of plugins that perform various DTP tasks for server-based publishing of PDFs that allow complete automation of publishing in all languages. This is particularly useful for XML-based publishing through Frame since it allows you to have the translation agency just focus on the translation and completely ignore the DTP (they don't even need to see the files in Frame).

Yes, you'll spend more money up front in developing the automated processing, but more than likely this will pay for itself within one publishing cycle. You do still need a "human" to review the files before calling them complete, but it should simplify the process and reduce costs.

Cheers,

...scott

Scott Prentice

Leximation, Inc.

www.leximation.com

Report · Jun 30, 2011

jgarc1a wrote:
(...)
For example (I could give you dozens of examples), in my native European Spanish, as in other European languages, the following must be avoided:
Four or more consecutive lines must not begin with the same letter.
Three or more consecutive lines must not begin with the same syllable.
Two or more consecutive lines must not begin with the same word.
(...)
Van, please, did your snippets and formatting rules also fix the typography (things like the 'must-not-begin' rule I mentioned above) of your target language documents?
Jesús

Jesús, the "rules" you mention have nothing to do with DTP or Typography – if they exist at all as "official" rules. And I strongly doubt, that there is any offical set of rules or official standard setting these rules. Maybe they apply to poems or some kind of belletristic literature or high-end livre d'art, but they surely do not apply to technical documentation. In the contrary, trying to be compliant with such fancy rules would be very counterproductive, would create enourmous extra efforts that cannot be justified in any way in tec doc – neither in efforts for time spent on following them nor in financial aspects, nor in linguistic quality consideration.

It might not even be possible to follow such rules in a translation process, as e.g. a bulleted list might have several entries all starting with the same word(s) in the source language. It might even result in wrong translations, inconsistencies or even heavy errors, if the translator would start trying to translate one and the same term with many different translations only to follow your rules.

I'm have a typography background myself and my typo heart is bleeding every day when I see standard tec docs, however I strongly recommend to stay with feeds on ground and rooted with reality. If we are producing large scale tec docs with xml and Framemaker and maximum automation in mind, we should surely use all the typographic possibilities tools like InDesign or even FrameMaker give into our hands, especially when we can automate them, to create great looking tec docs that are compliant with language/audience specific rules. But in the end we will probably never win the honorable TDC competition with dry tec docs 🙂

Kind regards,

Stefan Gentz

Report · May 31, 2011

Am 31.05.2011 um 14:28 schrieb Russ Ward:

I know that translation vendors make a lot of their money with DTP charges, so I can see an incentive to preserve them. It doesn't seem quite right, though, that well-structured documents would present a situation where more work was required, instead of less. The structure of these files is even valid against the DITA topic DTD, so I would think that there would be some kind of standard framework most vendors would already have in place for migrating content from our files to their system, and back again.

I have heard similar stories, about translators complaining about the amount of markup. If you give structured MIF files to the translation agency there is indeed an increase in internal markup, as not only formatting but also element boundaries are present. It can work, nevertheless. A client of mine always gives MIF files away for translation. In this case I would think that a modest increase of the translation costs could be justifiable to provide for that markup increase. But no DTP!

The golden way should be top give away XML files.

Basically, from what I understand, the TM tools still are just »string replacement engines« and have no knowledge about XML, the XML tags are treated like normal formatting tags and therefor there is a risk that some translator misplaces, doubles, or removes them – the result would be an invalid or not well-formed XML file.

It requires to talk to the agency and communicate the need to receive back valid XML files. They have to validate the translation result against a DTD or XML Schema and make sure to fix all possible errors before returning the file. AFAI can see this is not standard practice, yet (hopefully!). But again, no DTP!

- Michael

Report · May 31, 2011

Our in-house translation division has been doing non-exhaustive tests on translating XML files using Trados (not stand-alone, but in its Word interface form). It hasn’t been plain sailing.

The software seems to handle XML well if an element corresponds to a paragraph (or larger). But problems arise when we have what could be described as “in-line” elements, such as in a phrase like In Pride and Prejudice the main character is ….

Trados treats the element as a break in the sense, and doesn’t recognise the whole sentence or phrase, thus producing nonsensical fragmented translations.

The situation is complicated by French typography, where elements also mark superscript characters (used, for example, in ordinal numbers): “Lors de la 122e réunion du comité …”.

In a like vein, there is not a one-to-one correspondence between such elements from one language to another. One frequent translation of the French word notamment, for instance, is inter alia, which our house style requires to be italicised (and therefore wrapped in an element.

All this is so far inconclusive. Our translators are not yet using XML-based Word, which might make things easier; and I think the version of Trados they have is not the latest. But I suggest caution before jumping to the conclusion that translating text in XML is a simpler job than formatted WOrd (or other) text.

Report · May 31, 2011

David,

Trados Word interface is not the right tool for translating XML files. For this, you are supposed to use a Trados component called Tag Editor.

I assume you are working with the old Trados, as the last version—SDL Trados Studio 2009—has only one (non-Word) interface.

In my experience, translating Word files with SDL Trados Studio 2009 (which allows you to apply Word formats to the translated text) is simpler than translating XML files, which works more or less okay but, as you point out, often requires some post-editing to conform to the target language topography.

Jesús

Report · Jun 01, 2011

That’s useful to know, Jesús, thanks. I don’t know what version our in-house service has, being an end-user (responsible for reworking source material in FrameMaker).

We have to balance, of course, the advantages of using Word against the potential benefits of an XML-based system. In particular, the great bulk of the documentation translated is destined to remain in Word as “working documents”. Only a small percentage is elevated to the status of “publication”. Trados’ ability to retain the Word formatting is a time-saver in this context. In addition, many translators have built up their own library of ad hoc Word tools, chiefly search/replace macros that handle repetitive material such as the list of member states.

To simplify, it is likely that trying to make my job easier by aiming at clean XML coming out of translation would complicate the work of the translators.

Report · Jun 01, 2011

@David Crowe:

Our in-house translation division has been doing non-exhaustive tests on translating XML files using Trados (not stand-alone, but in its Word interface form). It hasn’t been plain sailing.
The software seems to handle XML well if an element corresponds to a paragraph (or larger). But problems arise when we have what could be described as “in-line” elements, such as in a phrase like In Pride and Prejudice the main character is …. Trados treats the element as a break in the sense, and doesn’t recognise the whole sentence or phrase, thus producing nonsensical fragmented translations.

There were perhaps some missunderstandings on how to process XML in Trados. Trados and most other professional Translation Tools can process XML. That is, they come with everything you need to process XML files. But you need to "teach" them your custom XML. Like you need to teach FrameMaker on how to process a specific XML flavour (by setting a structured application).

In Trados (and all other tools) you need to explain the tool: What is a block level element and what is an inline element. Block Level Elements do split into segments, inline elements don't segment. In (X)HTML typical block level elements are h1 – h6, p, table, tr, td, typical inline elements are span, em, i, b, strong, sub, sup etc.

Trados comes with a set of predefined settings for the most common languages like HTML, XHTML, dita, docbook, XLIFF and so on. However, if you have custom xml, you will need to create your own custom filter settings. Of course this should be done by someone who has excellent knwoledge of Trados *and* XML ... 🙂

Best,

Stefan Gentz

Report · Jun 06, 2011

>>this should be done by someone who has excellent knwoledge of Trados *and* XML

Ay, and there’s the rub. I can’t speak for my colleagues in the translation division, but we only beginning to feel our way in XML, and my knowledge of Trados is limited to a few demonstrations.

Thanks for your input, both to my comments and to everyone else’s.

Report · Jun 30, 2011

Hi David,

David Crowe wrote:
Our in-house translation division has been doing non-exhaustive tests on translating XML files using Trados (not stand-alone, but in its Word interface form). It hasn’t been plain sailing.

I overlooked the parenthesis until now. I can imagine that this was not plain sailing. Actually, this was the complete wrong approach. XML files must not be translated in MS Word with the Trados plugin. The Trados Word plug in is really only for translating native MS Word files and it's actually deprecated as even native word files are usually translated in the stand alone editor (TagEditor or Studio). MS Word has only basic understanding of your xml and cannot really display your xml in a proper way, that can be used for translation. You would need a complex integration for your custom xml in word first to read (and write!) xml with word.

You need to process XML with TagEditor or Studio and first start will be to "teach" Trados how to handle your xml.

David Crowe wrote:
Trados treats the element as a break in the sense, and doesn’t recognise the whole sentence or phrase, thus producing nonsensical fragmented translations.

At the time, this was probably more a problem of the way Microsoft Word reads your XML. As mentioned above, you need to process XML in TagEditor or Studio and you first have to setup the configuration file ("xml file format filter"), so that Trados knows the structure of your xml. First start is, to to read the DTD / Schema in the configuration editor and then fine tune / tweak the settings. In Studio you can also provide complex extra information like explanations of the elemens, so that the translator get's a better idea of what kind of element he is currently translating, or create complex rules (e.g. to exclude specific elements from translation or to make ambiguous elements contect aware (block level or inline level role depending on parent element).

We can go into more details via private message to make it not too much off topic here.

Kind regards,

Stefan Gentz

Report · Jul 01, 2011

Stefan – Thanks for your insight.

Our translators are excellent linguists but not all of them are technically-minded. It is not very long ago that some were dictating translations to be typed up from tape. Most of them are now comfortable in Word, but would hesitate to leave the safe environment, especially when it has in many cases been customised by means of simple macros to facilitate the job.

As in many walks of life, we can recognise an ideal target but accept that anything we might achieve is inevitably a compromise.

Report · Jun 01, 2011

@Michael Müller-Hillebrand:

Basically, from what I understand, the TM tools still are just »string replacement engines« and have no knowledge about XML, the XML tags are treated like normal formatting tags and therefor there is a risk that some translator misplaces, doubles, or removes them – the result would be an invalid or not well-formed XML file.

Not exactly. Modern tools like Trados have integrated XML parsers that actually do understand XML. E.g. Trados Studio 2009 even comes with an XPATH parser engine that makes it possible to e.g. lock specifc elements for translation, expose custom attribute for translation and write complex conditions like "expose this element for translation if it has the attribute foo="true", but not if the sibling of the parent element has the attribute comment". Also Trados can validate XML against an XML Schema during "check in" of the XML before translation and in during "check out" after translation. Also Trados Studio controls in real time your translation for correct tags, warns you when you delete tags or place wrong tags. It even refuses cooperation when you try to read invalid XML 🙂

Report · May 31, 2011

Thank you all for your replies so far. As a person investigating the merits of moving to a structured approach in my organization, this discussion gives me the impression that "in theory" a structured approach should improve the translation process, however, it's benefits may not be so apparent in actual practice.

I would be interested to have some more persons with practical experience using structured Framemaker for translation work (english to foreign languages) to weigh in about pros and cons.

The other conclusion i have from the responses so far is that the process is to provide XML files to a translation house that specializes in translating structured documents (including those that use specialized translation applications). I need to learn more about the process and would appreciated being directed to any tutorials that discuss the process, methods and tools.

Thanks!

Report · May 31, 2011

Jeff,

A well organized XML based project will definitely save translation costs. There are many advantages to the XML approach to translation management including:

Almost zero DTP rework costs - make the EDD/Template do all of the work!
Translation is application version independent - no need to wait for the Translation Memory/CMS system vendor to support the latest version of FrameMaker.

I have developed several multiple language applications where these principles have worked very well. From the development point-of-view there is more work to do up-front. All prefix and suffix text along with autonumber and cross-reference formats need to be fixed in the primary language, then translated and added to the EDD. Yes thirty languages supported by one structured template, including Asian languages. The only missing feature is support for right-to-left languages.

For the user simply changing a language attribute value on the root element should change all of the formatting of the book or document to give the correct results for that language.

In the translation system the content is translated as you would expect, but any reference to a language code in any XML attribute is changed to the correct xml:lang code for that translation job. When the translated text is opened in FrameMaker everything will be ready to run in the new language. This may even include applying the correct language specific master pages in some cases.

Structured authoring for translation really is the way forward. I asked for comments on this subject from translation agency KJ International Resources. They gave the advantages of XML for translation:

"Structuring reduces inconsistencies in the English (primary language)."
"Multilingual desktop publishing costs can be reduced as there is less time needed for format validation and this our practice."
"XML is CMS/online ready."
"The client can more easily input the XML into their Content Management System for a variety of uses and formats."

I hope this is useful...

Ian

Report · Jun 01, 2011

@Ian Proudfood

A well organized XML based project will definitely save translation costs. There are many advantages to the XML approach to translation management including:
Almost zero DTP rework costs - make the EDD/Template do all of the work!
Translation is application version independent - no need to wait for the Translation Memory/CMS system vendor to support the latest version of FrameMaker.

»... a well organized XML based project will definitively save translation costs.« – I have read sentences like this from a lot of consultants. And I have consulted/supported a lot of customers after those consultants left the stage. I always hear more or less the same from all of those clients. No question, I hear a lot of arguments for working with XML in tech doc, most of the arguments you mention included. Most of the tech writers are happy with the new structured FrameMaker and enjoy writing. And, cross your heart: Finally there's no alternative to XML in the long term if you take your tech writer job seriously. No question – working with pure XML in a professional information architecture in a structured, guiding editing environment like FrameMaker is cool, fun, faster and produces more open, more accessible, more reusable, more reliable, more consistent, in a nutshell: more valuable data.

But what I have never ever heard, and I'm talking about several hundred companies, is: We save more money on translation now. You might imagine that this is surprising me since many years. This is why I always ask: Did you save any costs in your translation projects? Surprisingly the answer is always: No. Actually some – no, wait: many – tell me, that their translation agency even charges more now, because they have a lot of new costs:

Costs, to customize their translation memory system to the clients custom xml,
costs to follow badly or not documented changes in the client's xml structure (DTD/Schema changes) in the TMS,
costs because of more engineering work like
- valididating xml in advance,
- fixing invalid xml exports,
- fixing invalid translations due to – sometimes massively – increased amount of tag errors because of tagging differences of "old" (legacy mif) and "new" (xml) tags,
- dealing with just too big XML files that need to be carefully split, so that the TMS has a chance to read it, or alternatively:
- "glue" the ten-thousand xml "snippets" to more handy chunks,
- project managers and translators that need to do additional checks, validations, verifyings - and often not knowing what to do with those cryptic error messages, meaning additional support costs

Of course, many if no all of these and many other problems I did not mention here can be solved. And many are not exactly system immanent problems but communication problems (like introducing or renaming elements/attributes but not documenting this and not communicating this to the translation service provider) or would apply to any system change (e.g. also when switching from Word to Frame). However, I do not know of any single translation company on this planet (and I know virtually thousands of them from countries all over the world) that reduced the price per word for just a single pence, just because the client switched over from Word/Quark/FrameMaker/InDesign/Whatever to XML.

Just ask your translation service provider: Will you charge me less per word if I send you XML instead of MIF? I would really be surprised to hear a "yes". And frankly, if you have ever compared a professional FrameMaker document with the same document in xml format in a professional system like Trados: There is actually no difference that would justify any price difference. The text is the same, the amount of words identical, the number of tags is identical, it even looks identical in the translation system (I can post screenshots if you like). From the translation perspective there is no single reason why a translator should charge a single pence less.

So, it's a modern myth, that switching to xml reduces translation costs. That might be true, if you come from a really medieval documentation szenario with MS Word or the like, with manual formatting without any styles and so on (I see tech docs every day where even the TOC is typed in manually!!!) and swith from there to a modern structured xml authoring in combination with other supporting tools like authoring memory / authoring assistance, controlled language, translation memory and terminology managent and control, snippet based content management and so on. That will increase the consistency and quality of your data, which will reduce translation costs in the long term. But the truth is: This has nothing to do with XML per se, but with professional writing and professional management.

So, what's left in the money saving story? No more DTP in the target languages? I always hear, that with XML and FrameMaker you do not have to "format" the translated document. The truth is: If you have a professionally formatted (unstructured) document, you don't have to take care of it, too. Modern tools like Trados keep 100% of the formatting 100% correct in the translated document. If the underlying template is intelligent enough to take account of text amount changes due to longer translations, and if you don't have too many local formatting overrides, the DTP is actually zero and can be reduced to a few mintes/hours for "flying" of the document to check out for unexpeted problems wich can occure in both structured and unstructured documents.

Just to give some numbers on this: We are processing every day technical documentations for a quite big company. A typical documentation from them is about 250 pages in unstructured FrameMaker 9 (source language is English). Until now they were resistent to all my XML pushing. The Documentation is based on a straight, simple template (with our help "reduced to the max") and there are no formatting overrides (a script automatically checks this). The post translation Quality Assurance effort is - depending on the target language - usually something between 1 to 4 hours – that's a few seconds per page for the languages where already a lot of past Quality Assurance Steps went back into the Translation Memories and up to a minute per page for more "problematic" languages).

So, again: XML will not save you a single pence on translations. But it might help you to produce more open, more accessible, more reusable, more reliable, more consistent, in a nutshell: more valuable data. But if you already have properly set up (ustructured) FrameMaker Documents and already work with a professional translation memory system, you will be quite disappointed to learn, that the impressive money saving promises you recently saw on that great PowerPoint slides melt down to a few bucks over a couple of years.

Kind regards,

Stefan Gentz

Report · Jun 02, 2011

For me, this is the most interesting and helpful thread I've seen in some time. I'd like to follow up with this question...

A little while ago, we had approximately 250 pages of structured FrameMaker content translated. This was a second translation to pick up updates from a previous initial translation, same vendor. Anyway, I was charged $6.00 per page and $5.00 per table for formatting, in addition to a $1.00 per page "pre and post processing" fee. The end result was that formatting charges were much higher than the actual translation charges, especially as we were charged to format every page/table/etc., even though the majority of the content had no changes at all since the last time.

We gave the vendor structured FM files with a very simple and rigidly-followed EDD, actually valid against the DITA topic DTD although technically not DITA. These files are very consistent and organized.

Can somebody comment in general about whether I am getting ripped off here? From Stefan's commentary, it seems that I should expect zero DTP charges, given the very simple and consistent nature of these files.

Russ

Report · Jun 02, 2011

Russ,

Did the translation house require the DTP charges? If not, you could have done the DTP yourself, and it would likely have been cheaper. As long as the translation house does not screw up the structure, you can fix tables and another oddities yourself. These are look things that do not require knowing the language.

Van

Report · Jun 30, 2011

Hi Russ,

Russ Ward wrote:
A little while ago, we had approximately 250 pages of structured FrameMaker content translated. This was a second translation to pick up updates from a previous initial translation, same vendor. Anyway, I was charged $6.00 per page and $5.00 per table for formatting, in addition to a $1.00 per page "pre and post processing" fee. The end result was that formatting charges were much higher than the actual translation charges, especially as we were charged to format every page/table/etc., even though the majority of the content had no changes at all since the last time.
Can somebody comment in general about whether I am getting ripped off here? From Stefan's commentary, it seems that I should expect zero DTP charges, given the very simple and consistent nature of these files.
Russ

Sorry for my late reply, I was quite busy after my last post.

To be precise, I did not say, that *you* should expect zero DTP charges. I was writing, that *theroretically* you can expect zero dtp charged – if you have perfectly set up formatting templates that drive the formatting of your structured content in a way, that it will make post translation dtp efforts superfluous. Without knowing your documents and having more details about the excat translation workflow, I can not (and should not) judge if the charges of your LSP were justified or not. However, what sounds really strange to me is, that they charged you $5.00 per table. I know that charging extra for "tables" was done decades ago – when there were no real tables in DTP programs, and "fake tables" were typed in manually with tabs, hand-drawn lines, etc. However, charging extra for DTP of tables (on top of charging for DTP per page) sounds in fact very, very unusual to me, especially for professional FrameMaker documents. Maybe you have very comlicated tables with very narrow table colums but very much text that need a lot of manual tweaking in the longer target languages necessary? E.g. to fix long words breaking without hyphenation over two lines - things like this? However, if there is nothing really special in your tables, you should definitively discuss this with your LSP and ask them explicitly why they charge extra for tables.

Beside this, $6.00 for DTP sounds like a fair price to me for structured FrameMaker documents. To give you an idea, prices for DTP of structured FrameMaker Documents rage from $3.50 to $15.00 depending on complexity and target languages. $1.00 for "pre and post processing" is a usual standard price as well. With "pre and postprocessing" your LSP probably means Language Engineering tasks like the following: source xml validation, create translation project, check files into translation system, validate, verify and QA-Check after translation, check-out files from translation system, check translated files, create target language FrameMaker book. Market ranges are from $0.5 to $2.50 per page. Other LSPs charge a word count based fee for this (usually $0.01–$0.05 per word). Others hide engineering efforts in the word price, project management fees or similar.

So, if your documents are "standard" documents, and if you asked your LSP to do the DTP for you, $6.00 for DTP/page and $1.00 for Language Engineering per page is absolutely normal standard, average prices. The charge per table is unusual and surprising and should be clarified for future projects.

Of course you can also send me a private message and we can go into more details or even discuss the process with your LSP.

Kind regards,

Stefan Gentz

Report · Jun 01, 2011

@jeffc2010:

I keep reading about how a structured approach can improve the translation process (from english to foreign languages), however, i can't seem to find specifics about a particular method or tutorials about how to go about it (specifically). My question is, how (specifically) can structured framemaker be used for translation from english to foreign languages?

First of all: A well designed structured FrameMaker application with a well-designed template that covers all the needs for multilingual production and which is based on native XML files can actually speed up and optimize your translation process *a little bit* and reduce your post translation DTP costs *more or less*.

But the same also applies to unstructured FrameMaker with a well designed template. Actually the "DTP money saver engine" behind structured FrameMaker is only a clever template that perhaps gets or gets not a few smaller extra tweaks from the EDD which are not available in "unstructured" FrameMaker (like "keep last bullet point always together with the second to last bullet point in my list"). The truth is: Unstructured FrameMaker documents that are based on a straight and clean template and have no local formatting overrides will produce (or produce not) the exact same amount of post-translation "DTP" cost as structured documents.

Actually for translation memory based processes it doesn't make that much of a difference at all. That is, in the "classic" scenario you feed MIF files into the translation memory and get translated MIF files back – with all formattings exactly as in your source files. All paragraph, character and tables styles, all master and reference pages, simply everything in your FrameMaker document will be the same as in your source language files. Only the text will be replaced. Even all your ugly local formatting overrides will make it into the translated file. All leading translation tools have highly sophisticated filters to process your MIF files perfectly.

Same with structured FrameMaker. You can save them to MIF as well and they will be processed in exaclty the same way as unstructured FrameMaker and no structure information will be lost.

So, it doesn't really make a difference if you feed structured or unstructured FrameMaker documents into a professional translation process. Both documents will come back with the exact same formatting as your source document. That means also, it doesn't make a difference in terms of post translation editing efforts. The amount of work you have to spend after translation to make your translated documents look great and "customer ready" depends on the underlying framework. That is, the better thought through your underlying formatting template is, the less work you will have with the translated documents. I have already created both templates for unstructured FrameMaker as well as structured applications that reduce the post translation DTP efforts to zero. Not the question structured vs unstrucured makes the difference. I have seen enough badly set up EDDs and structured FrameMaker documents where it did need days to fix the layout of the translated documents, so that I can tell you for sure: Working with structured FrameMaker is no guarantee for cost saving at all. In the contrary. Finally the same applies for both unstructured and structured documents: You need an experienced expert (or a group of experts) to set up the tools and processes in a way, that works. Too many "experts" promise big savings and do not even consider that a document life cycle doesn't end with writing the last page in the source language.

When working with native XML files in FrameMaker (what I prefer), than the process is a little bit different. You will need to customize the translation tool to "understand" your custom XML. That even applies for the "big" frameworks like docbook or dita, when you have customized them for your needs.

Cheers,

Stefan Gentz