FrameMaker is a
powerful and mature authoring solution, well suited for unstructured data, like
traditional manuals and long documents. This well-established authoring tool
also now serves well as an "out-of-the-box" DITA/XML editor. Because
FrameMaker has been around so long, many customers have active legacy files
that were originally created five, 10 or even 15 years ago. Many hands may have
touched your content over many years; as a result, your content may be riddled
with hidden objects that can add unwanted expense to the translation process.
This
blog focuses on practices to avoid in order to avoid hidden project costs. This
blog also assumes some mid-level skill with FrameMaker on the reader's part, as
the focus is on advanced features. However, most of the undesirable practices
mentioned in this blog also apply to InDesign and Microsoft Word content as
well. GPI will be covering best practices for these other products in future
blog entries.
Here
is the first half of Globalization Partners International's (GPI) "top
ten" list of the worst mistakes FrameMaker authors frequently make with
content submitted for translation:
- MARKERS PLACED IN MID WORD:
this may seem innocent enough; you have inserted an index marker behind
the fourth character of "California." Believe it or not,
repetitious placement of markers within words can slow down the
translation process considerably. When FrameMaker files are prepped for
translation, they are first saved to MIF,
then converted to a special form of RTF for Trados (in most instances.)
Text strings are segregated as "segments" based on text between
format codes. An index (or any other) marker in mid-word will divide that
word into two segments that will be perceived by the linguist and
translation software as two separate words. This prevents translation
memory (previously translated content) from providing an "exact
match." This leads to unnecessary additional translation expenses.
SOLUTION: use the FrameMaker FIND feature to search for ANY MARKER, and locate each marker that is inserted within a word. Use CUT/PASTE to move that marker to the beginning or the end of the word. This will ensure the most accurate, cost-effective translation, giving your department more money for future projects. - UNANCHORED GRAPHIC ELEMENTS IN
THE PAGE MARGIN: many experienced FrameMaker users are not aware of the
software's many options for positioning anchored frames. As a result,
there are thousands of complex, tech doc FrameMaker files which have unanchored
artwork that "floats" in the outer margin of the page. Such
artwork has been manually dragged into position to "happen" to
line up with the correct baseline of appropriate source language text.
(Note: this problem is far more common with InDesign documents).
When translation takes place, text expansion will cause the baseline of appropriate source text to move down several lines, but the artwork is static and will stay in its original place. DTP staff at your language service provider (translation vendor) will have to manually move each instance of such artwork to the new location in the target languages. Obviously, this adds considerable unnecessary billable time to your project.
The screen capture below shows a simple anchored graphic (oval) that is anchored to the red word (note the marker symbol in front of "BAR"). The exposed menu shows the Anchored Frame options used to place this graphic in the outer margin of this "side head" style document. - MARKERS ARE LIMITED TO 255
CHARACTERS: one limitation of FrameMaker (and many authoring products) is
that markers have a maximum of 255 characters. This is especially critical for the most popular type
of markers: Index. Because language translation can cause text to expand
up to about 30%, you should limit the character count of your markers in
English source text to about 170 to 175 characters. This will ensure that
your translated documents will not have generated Indices with entries
that are "clipped" with missing characters, because markers
exceeded the 255 character limit.
- LISTS OR CONTENT THAT MUST BE
ALPHA SORTED: many authors who are used to only viewing English source
files are not in the habit of considering how alpha ordering will change
in all target languages. If you have a list or glossary that must be in
alphabetical order after translation, (a) use a Table, with one column for
the term and a second column for the definition, or (b) use glossary
markers. Note: glossary markers are more limited due to the 255 character
limit mentioned above. If your glossary is in a table format, after
translation, linguist/DTP staff can do a simple " table sort by
rows" in FrameMaker that will restore correct alpha order in the
target languages. If the terms (or list content) is brief, with fewer than
255 characters per entry, post-translated FrameMaker books can generate a
new Glossary "list" that will be in correct alpha order.
If neither of these methods are used, more manual (and expensive) methods must be used to restore correct alpha order for your target languages in FrameMaker. Usually commented PDF files or Word tables with text extracted via COPY/PASTE have to be created by a linguist to guide DTP staff in restoring correct alpha order in the target language. This would cause your projects to cost more than if the recommended methods mentioned above were used. - FORCED UPPER CASE STYLE: in
English content, a popular style is to have certain headlines appear in
ALL CAPS, and then have the running page headers that pick up those
headings appear in Upper/Lower case. Although this may seem attractive in
English, it does not work well at all for any Asian Script language. It
also causes complications with some languages like Turkish, which have
multiple hard code accented vowels, and can make linguistic proof edits
more error-prone. See the screen capture below for an example of this
style.
Example: a FrameMaker chapter has gone through linguistic review. The linguist has indicated correct spelling in ALL CAPS (because it matches the headline display, which has a paragraph tag that "forces" UPPER CASE display). The agency DTP staff must remember to enter corrective text in Upper/Lower case within the heading in body text in order for correct running page header display to be achieved.
Another issue with this style is that in English there are no hard, established rules for which words to capitalize if "Initial Cap" styles are being used in paragraphs. Usually proper nouns are capitalized and articles (and, or) are not. Initial Cap heading styles are not used in many regions like Eastern Europe, and will cause consternation (and lost time) for the linguist doing translation and the linguistic staff doing linguistic review. Again, increased project time may result from this seemingly innocent style choice.
NOTE:
several times we have mentioned that "additional billable time may
result." Please note that any credible translation partner will warn you of these cost issues ahead of time when your
project is quoted. Part of document analysis for FrameMaker involves hunting
for various document quirks, like misplaced index markers and poorly structured
lists that must be alpha sorted after document translation.
SUMMARY:
If you follow all of these guidelines in preparing your FrameMaker content
before submission to translation/localization, you may decrease some portions
of your project costs by as much as 33%. Naturally, you can use the money saved
with these techniques to move your content into more languages, extending your
company's reach into even more global markets.
This
is Part One of our "top ten" list. We will be posting Part Two of
this list next week. We encourage you to click on the RSS feed
of this blog so you can be updated automatically as we post periodic content in
about several categories of translation and localization issues.
Our
intention is to provide you with practical guidelines that will empower you to
submit the cleanest content possible, and substantially reduce translation
costs by eliminating unnecessary corrections.
No comments:
Post a Comment