Automating Document Translation Formatting with Structured FrameMaker 10

September 22, 2011

GPI has written a number of blogs about the benefits of FrameMaker 10, since it is one of the most popular source file formats for single-source publishing and high page count projects. There are a huge number of advantages to migrating content into structured FrameMaker with DITA or XML structure. One of the chief benefits is the number of ways that formatting for document translation can be automated, or made virtually "fool-proof." These benefits are magnified by the number of target languages involved when FrameMaker files go through document translation.

Adobe has recently been hosting a number of "deep dive" webinars that cover virtually every aspect of creating and managing a structured document project in FrameMaker. Fortunately, all of these webinars have been recorded and are readily available. We will reference a few of these helpful video demos as we touch on the highlights of controlling document structure and formatting with structured FrameMaker 10 for document translation.

Unstructured FrameMaker is more limited in formatting for document translation

Many clients still use "regular" or unstructured FrameMaker for source-language documents in preparation for language translation services projects. With enforcement of best practices, consistent use of paragraph and character tags, and minimal "format overrides," this is usually a successful venture. Ironically, the file format (MIF) used for translating FrameMaker files is generally more error-proof than Microsoft Word. However, there is a significant difference in the way document assets for unstructured FrameMaker files are handled during the translation process.

Pre-translation engineering file processing involves saving FrameMaker documents to MIF (Maker Interchange Format). This is a fully documented, ASCII-based file format that preserves every facet of the document, including all formatting and format definitions. Unlike XML or DITA, there is no true separation of content from formatting. The "template" (master page layout, character and paragraph formats) is literally fused inside the document.

As a result, after document translation occurs for unstructured FrameMaker documents, the MIF is converted back into binary *.fm files. Then, a language-specific template often has to be manually imported into all chapters of a book file. Books typically required 2 or 3 templates, e.g. one for TOC, one for Chapters and one for Indices or Appendices. The management of language-specific templates can be tedious and potentially error prone. Due to the manual nature of this process, additional post-translation format-proofing may be necessary.

Another issue with unstructured FrameMaker is that it is relatively easy to make scattered and inconsistent "format overrides." An extreme example would be a "body" paragraph that has had indents, font and bolding changed to make the paragraph resemble a "Heading 1." This, of course, makes global updates to formatting difficult, if not impossible.

How structured FrameMaker and DITA/XML handle formatting

As with conventional DITA or XML applications, structured FrameMaker allows separation of formatting from content. Formatting comes either from an external template or a series of "format rules" that are contained in the EDD (Element Definition Document).

The EDD closely parallels the structure of a DTD, but it contains some commands and rules proprietary to FrameMaker. In an extremely simple structured FrameMaker application, the EDD can simply "map" conventional paragraph or character styles to specific XML or DITA elements.

Why developing formatting for FrameMaker/DITA takes less time

Ironically, the fact that every unstructured FrameMaker document has a " template" fused inside of it is a huge advantage. This means that any well-formed legacy FrameMaker document can become the basis of the template used for structured FrameMaker. In some cases, a legacy document may need virtually no modification at all to achieve this goal.

Most conventional DITA authoring solutions require the developer to replicate all formatting from legacy Word or FrameMaker documents in CSS or XSLT style sheets. FrameMaker virtually eliminates this step. In addition, the format choices available in the EDD under format rules are an extremely close parallel to the format choices found in conventional FrameMaker paragraph, table and character "designer" menus. There are a number of ways in which you can add formatting to the EDD.

Context-sensitive format rules in FrameMaker 10

Context rules in the FrameMaker EDD fall into two general categories: (a) context rules that are influenced by containing elements and (b) context rules which activate based on an attribute value.

Many users are familiar with "context-sensitive" formatting in structured FrameMaker. Some of the built-in templates, have nested lists and the rules of the EDD will change a list bullet to a dash, if the list item is "demoted" and contained by another list, for instance. In this case, the element formatting is being determined by the containing element.

Although this type of formatting may be accomplished in almost any XML editor, the process for setting up formatting rules in FrameMaker is generally perceived as more intuitive and less complex than those required to create formatting via XSLT.

Context-formatting based on attributes is not as widely known. GPI documented this feature in a joint case study with Adobe, " Adobe Success Story: Major Medical Device Manufacturer (MMDM)." We also discussed this solution in our previous blog, " FrameMaker DITA and Translation: Eliminate Round Trip to XML."

Format changes triggered by a Language Attribute

The following screen captures illustrate how the Lang (language) attribute can trigger automatic format changes via the EDD, which are automatically applied to the XML files when they are opened in FrameMaker:

This shot shows the source English file formatting for the [note] element in XML:
This shot shows how the Lang attribute has been set to Bulgarian in a translated version of the file:
This shot shows the portion of the EDD with a context rule for [note] that is dependent on the Lang attribute being set to Bulgarian. Notice that both the left indent and tab values are increased, and the word "note" is replaced with the Bulgarian equivalent, "Забележка".
This final shot shows how the same [note] element is formatted differently in the FrameMaker XML file that has a Lang attribute set to Bulgarian. Notice the substituted text in the paragraph prefix and the increased tab/indent:

Why are formatting rules for XML documents easier for FrameMaker users?

Since FrameMaker has been around for 25 years, there is an enormous pool of talent composed of content creators and editors with at least a moderate set of FrameMaker skills. For a publisher who knows how to create paragraph formatting for regular, unstructured FrameMaker documents, the process of setting up context format rules in a FrameMaker EDD is highly intuitive.

This is because the EDD is actually a structured FrameMaker document, and the structure view will actually prompt the designer with paragraph format elements that may be "legally" inserted in any particular location. The list of available options for formatting very closely parallels how formatting choices are clustered together in the FrameMaker paragraph or character designer.

Benefits of a single template for multiple languages

A few years ago, when the majority of FrameMaker users were using regular (or unstructured) FrameMaker, automated, language-based formatting was not as easy to achieve. As GPI has documented in previous blogs and webinars, it is now possible to have a single structured template automatically provide formatting for more than 28 languages. This includes such language dependent issues as:

Changing all fonts for Asian languages like the Chinese language , the Japanese language and the Korean language
Automatically adjusting paragraph prefix text
Automatically adjusting hanging indents (as illustrated above) to accommodate translated text expansion for words like "note", "caution" and "warning"

Before the advent of a single template for FrameMaker XML files, most language translation services providers (or your translation agency) had to maintain multiple "look-alike" templates that had only a few differences between them. Obviously, the increased error rate of not updating all instances of "note" in a particular language template was high.

This blog covers just a few of the strengths of structured FrameMaker that you can capitalize on for increased productivity, whether your projects are English-only, or whether you have multiple language document translation projects that span dozens of languages.

The following are some Adobe videos on the use of structured FrameMaker that GPI has found particularly useful. (Note, you will need a free, Adobe account in order to view the webinars):

GPI's Multilingual Desktop Publishing Services

Globalization Partners International provides many services with document translation and website translation that involve multilingual desktop publishing services. This list below highlights some of the more common products used in such projects:

You may also find some of our previous blogs on desktop publishing useful:

Please contact GPI at info@globalizationpartners.com or at 866-272-5874 with your specific questions about Microsoft Word and your project goals. A complimentary Translation Quote for your project is also available upon request.

Category:: Document Translation
Tags:: Adobe FrameMaker, XML, DITA, Multilingual DTP, FrameMaker EDD

How RoboHelp 9 benefits Translation Projects - 1 Food & Beverage and Hospitality Translation Tips, Part 2

Comments

On Sep 24, Mohamed said:
Great article. Do you think Arabic and other bidi languages can be handled in FM10? Any idea?
On Sep 24, Tom Aldous said:
great article. I enjoyed the high level of technical accuracy.
On Sep 25, Maxwell Hoffmann said:
Tom, thanks for the vote of confidence.

Mohamed, the current version of FM 10 does not handle Arabic or any other BiDi languages. I do not know if this is planned for the future or not. At GPI we have found that it is relatively easy to export FrameMaker to Word format, preserve para tags and open up the exported files in InDesign. From there, the project can transit into ME InDesign, which does support BiDi, and be published separately, with similar look and feel. Click at the bottom of our Blog Home page to "view all blogs" and search for "Arabic" and you will find a number of useful blogs about the Arabic language.
On Sep 25, Mohamed said:
Thanks Max! This is really good to know, but apparently I need to investigate further on 'para tags'. Is there a particular way to export Word documents from FM with para tags preserved? Do you need to do any kind of mapping into InDesign to make it work? I am sorry to bother you with all these questions. I will investigate further when I have a chance. Thanks again Max for sharing you valuable knowledge with us :-)
On Sep 27, Tom Aldous said:
For those of you that did not know, Max Hoffmann was my first and only FrameMaker Teacher a couple of decades ago.

Contact Us!: +1 703-286-2193 +1 866-272-5874 On-Line live chat info@globalizationpartners.com

Nicolás Cárcano - Desktop Publishing Specialist
A native speaker of Spanish, Nicolás has expert skills on both Mac and PC platforms with many DTP applications including Adobe Tech Comm Suite, specifically structured and unstructured FrameMaker, InDesign, Illustrator, Photoshop and others. He also has advanced skills in Microsoft Office products like PowerPoint and Word, as well as Quark.