Transcript of "Lavacon 2011: Managing Translations in Frame DITA without a CMS"
Managing Translations inFrameMaker DITA without a CMS Lavacon November 16, 2011 Mollye Barrett
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
Development: Frame and DITASelected three existing FrameMaker publications representativeof 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.
FrameMaker DevelopmentBeta book: developed FrameMaker conversion table to structurecontent• 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
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
FrameMaker EDD: LanguagesLanguage-specific rules• Based on xml:lang• Labels (for note, title)• Fonts (for Japanese, Korean, Simplified Chinese)
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)
FrameMaker Template• All paragraph and character formatting• Page layouts• Table formats
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
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
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
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
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)
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 IDs 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
SVG Transform Transformed: GermanOriginal: English
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
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>
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
Content TrackingCan’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.
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