This document discusses managing translations of documents created in Adobe FrameMaker without using a content management system. It describes using FrameMaker as a DITA editor, creating custom element definition documents and templates to map DITA elements to FrameMaker styles. It also discusses handling variables, images, tables and publishing across multiple languages. A database was created to track topics, maps, publications and the translation workflow. Future steps include migrating to a CMS and developing XSL-FO transforms.

1. Managing Translations in
FrameMaker DITA without a CMS
Lavacon
November 16, 2011
Mollye Barrett

2. FrameMaker End-to-End
• Robust GUI environment: Client in unstructured Frame 7.0
• Adobe FrameMaker as DITA editor
• FrameMaker DITA challenges include translation
• Author DITA in FrameMaker for translation into 20+ languages
• Multiple FrameMaker templates and EDDs
• Content analysis
• Document conversion (conversion tables)
• Detailed file structure (in lieu of a Content Management
System)
• Variable handling in multiple languages
• Incorporate application code strings (in multiple languages)
into DITA topics and SVGs

3. Development: Frame and DITA
Selected three existing FrameMaker publications representative
of work products (print and PDF only):
• Removed unused styles, standardized style names
• Performed a content audit
• Nine outputs
• 22 languages for every title and output
• How well content breaks into topics
• What required rewrite
• Method for determining reuse: approximately 80%
• Identified content for Beta book for development
• Used AXCM for XPath-based rules to filter topics for product
and output format.

4. FrameMaker Development
Beta book: developed FrameMaker conversion table to structure
content
• Reorganized large documents into small individual topics.
• Created custom EDD (Element Definition Document) and
“mapped” DITA elements to paragraph, character, and table
formats of original template; maintained look and feel
• Modified read/write rules associated with the structured
application for smooth round-trip between DITA XML and
FrameMaker
• Eliminated template formats from the template; used EDD rules.
• Leveraged available DITA attributes; outputclass
• Autonumbers and prefixes out of template and in EDD using
language-specific rules based on the xml:lang attribute
• GOAL: One EDD and minimal number of templates

5. FrameMaker EDD
• Use of @outputclass on several elements to specify
formatting not predictable via context
• Full-page images vs. in-column images
• Ad hoc table cell alignment
• No specialization or DITA-FMx plug-in
• Client uses DITA-FMx for archiving translations but not
primary authoring
• List of elements and attributes: like a DTD
• Rules to map elements to Frame styles based on context
and/or attribute values
• Picklist of values for attributes
• @product, @audience, @outputclass

6. FrameMaker EDD: Languages
Language-specific rules
• Based on xml:lang
• Labels (for note, title)
• Fonts (for Japanese, Korean, Simplified Chinese)

7. Not in FrameMaker EDD
• Formatting information
• Most paragraph and character designer properties
have EDD element equivalents, but…
• Preferable to map elements to style in template to
provide one central place for formatting changes,
instead of throughout EDD
• Exceptions
• Special fonts for non-European languages
• Character formatting for some inline elements (e.g.
uicontrol)

8. FrameMaker Template
• All paragraph and character formatting
• Page layouts
• Table formats

9. FrameMaker Final Deliverables
• Five templates
• Manual
• Manual without sections
• Quick Reference
• Pocket Guide
• Preoperative Checklist
• Five EDDs
• One for each publication type; very similar but
enough differences to require separation

10. Conversion to DITA
• Used FrameMaker conversion table
• Template style usage very consistent
• “Crosswalk” spreadsheet used to map existing Frame
styles to most appropriate DITA element
• Minimal manual clean-up needed
• Each book “chapter” converted to one large DITA
document
• Consultants and writers determined how to split into
individual topics
• File naming conventions
• Consistent level of granularity

11. Frame Conditional Text: Not
Used
• Conditional Text
• Eliminated conditional text and replaced with
@product, @audience (pick list built in EDD)
• Mainly inline elements (uicontrol, etc.) but some
block elements (step, li, etc.)
• Structure changes needed to accomodate

12. Frame Variables: Not Used
• Variables
• Original template contained 100+ variables
corresponding to software menu options
• Value of variables came from developer-generated
XML file
• Easily translated; wanted to keep this functionality
• Created separate file containing each variable as a
conref source (<varname>)
• This file still developer-generated, now in DITA
• Still easily translated

13. Frame Multi-Object Images:
Not Used
• Images in original documents were line drawings of
screen overlaid with text boxes containing variables,
simulating screen shots
• Easily translated, reduced need for language-specific
images
• Initial goal was to use SVGs (Scalable Vector Graphics)
to maintain functionality (i.e. translate text as element
within SVG)
• FrameMaker cannot “look inside” SVG code; this
solution not workable at present
• For same reason, cannot show/hide callouts (Frame
cannot interpret @display value)

14. SVG Solution
• Developers created a two-step XSL transformation utility that
accepts an SVG input file (English), an associated DITA string
file (English) and inserts the string ID's into an output SVG file.
The utility transforms output SVG from step English into any
language the user specifies. A string file is specified for each
language the user requires for output.
• Developers designed and developed a web interface the
writers use to access the transformation tool. This web
interface allows users to specify information required for
output:
– input SVG
– input DITA string (source)
– input DITA string(s) (target)
– target language(s) for SVG translated output

15. SVG Transform
Transformed: German
Original: English

16. Folder and File Structure

17. Other Frame Challenges: Image
Sizing and Pathing
• Image sizing
• Frame uses DPI, converts to @height, @width
• No units in XML code (e.g. <image height=“23”/>
• @height, @width not accessible in Frame
• overcome with FO, but publishing with Frame only
• Image pathing
• Frame uses backslashes by default
• When manually editing path, user cannot enter
backslashes, must change all to forward slashes
• Re-linking image via Missing File dialog does not
dynamically update @href path

18. Other Frame Challenges:
Tables
• Mapping between DITA table elements/attributes
handled by read/write rules
• Trick is learning what corresponds to what in Table
Designer and Custom Ruling & Shading dialogs
• Many Table Designer and Custom Ruling & Shading
options do not have DITA equivalents
• Most formatting applied based on <tgroup> not
<table>

19. Other Frame Challenges:
Publishing
• Ditamaps converted to Frame files and included in Frame
book
• Appropriate template applied during conversion
• Generated TOC, Index
• Frame book filtered based on @product and @audience
• Use free AXCM plug-in
• More robust than standard Frame filtering
• Preferable to ditaval
• Client produces English deliverables
• Translation agency produces all others
• Process is largely manual with many opportunities for
error and omission

20. Content Tracking
Can’t find it, can’t use it!
• Developed a customized Access database to track
DITA topics and related FrameMaker books. Loaded
database with current data including current topics,
ditamaps, Frame composite docs, Frame books and
publications. Team maintains topic names, paths,
attributes.
• Database backend resides on a network location
accessible to all writers and translation coordinators.
Each database user has a copy of the interface on
their machine.

21. Tracking Topics

22. Tracking Maps and Topics

23. Tracking Publications

24. Tracking Topics for Translation:
Report

25. Translation Workflow

26. Next Steps
• CMS selected, migrating in December
• XSL-FO development, requirements based on EDD
and templates
• Transform all content in OTK before importing to
CMS
• Include processing on SVG as part of DITA transform
with OTK

27. Questions?
Thank you!
Mollye Barrett
mollye@clearpath.cc