We know you love MadCap’s Flare authoring tool. It has made creating your tech pubs easier, faster, and more polished. We also know it took time to get there—using Flare well requires a commitment by technical writers, but the investment is well rewarded. Flare is a robust, feature-rich authoring tool and therefore it has a steep learning curve. All those excellent features: snippets, variables, tags, target templates, etc. require you to make choices about how to structure your Flare projects. All those small choices add up to lots of automation as your Flare projects grow and mature.
During translation of your Flare projects, we translators must account for and either maintain or adapt all those choices to work in all the target languages you need to support. This requires time and effort. Of course, it is merely a fraction of the time you spent designing and perfecting your Flare projects.
In a perfect world, we would simply translate the content in your Flare project, swap the files and press build and everything would work exactly as in your original project. Amazingly, the process can get close to that, but the reality is that the software, translation process and tool sets, and languages themselves introduce other layers of complexity to your already complex Flare projects. To guarantee that your translated Flare project works as well as your original Flare project, desktop publishing and some re-engineering are needed. Why is this the case?
Before delving into the “why”, let’s address the “what”—What do we mean by desktop publishing in the context of translated Flare projects? The traditional definition of desktop publishing includes the layout of text in the format of the final output. Is your document a brochure or a bound book? Desktop publishing addresses that format and how text will fit into it. But in the context of translation, desktop publishing includes this traditional definition as well as the additional tasks of correcting for technical limitations of translation and desktop publishing software. Such as?
Language
Text fit (in callouts, footers and headers, table headings, and image overlays)
You may have heard of “expansion” and “contraction” in the context of translation. These refer to the respective phenomena in translation. When English is the source language, there is typically expansion of the target text. In languages like Spanish, Portuguese, and Russian expansion can be 20 – 30% or more. There are diverse types of expansion:
- Word count expansion – The total number of words in the translation is greater than in the source language
- Word length expansion – Individual words and phrases may be longer in the translation than in the source
- Character height expansion – In languages that use other writing systems the height of individual characters in the target language text may be taller than in the source language
Word count expansion can cause pagination to shift, therefore forced page breaks must be avoided in the source. If you require all new sections to begin on a left-hand page, for example, the translated versions of your Flare project may require that blank pages automatically be inserted to enforce this requirement if they are not already in your project.
Sorting
Depending on the target language and the script it uses, it may be necessary to manually sort things like glossaries, tables of content, and indexes in the target Flare project. Flare has wonderful multilingual capabilities, but it may not be able to support proper sorting for all languages. Many languages use phonetic sorting (e.g., Japanese) and normal alphabetic sorting will not work.
Within topics in lists and tables that are sorted alphabetically in the source language, the translated version of such lists may also require manual sorting depending on how the source content is set up and the requirements of the target language.
Limitations of technology
Skins
Flare includes project skins for some frequently used languages, but Flare cannot provide skins for all languages. Skins can be translated from scratch and then reused in subsequent projects. Your translation partner should be able to account for this and include translation of the skin contents the first time a new unsupported language is involved.
Bugs
From time to time there may be a software bug that impacts the translation of your Flare project. One example is a bug that requires translated images to be manually copied into the Flare project as opposed to simply remapping the image location. Bugs are a fact and usually they are minor inconvenience. The trick is to find workarounds that are quick and easy.
Some text that appears in outputs must be translated directly in Flare
There is a limited list of text that must be translated within the Flare software itself since this text cannot be exported as part of your Flare project content. Experienced Flare localizers already have accounted for this text and will ensure it is translated and inserted via the Flare interface into your project.
This is not an exhaustive list of potential issues that can arise while working with translated Flare projects. Given the complexity of both translation and publishing tools, experience counts for a lot when engaging a translation provider. Your translation partner should not be surprised when issues arise when publishing translated content in Flare. On the contrary, your translation partner should foresee and mitigate for these issues as part of their standard work process. If your organization is about to engage in first-time translation effort involving Flare, the best practice is to request a Flare project localization assessment from your translation provider. This is a case where preparation will guarantee proper performance.
Main image: © Unsplash
