Appropriately planning for the overall life of a project and its translation is paramount. Failing to do so can result in technical debt and troublesome fees, as well as unimaginable frustration and headache. Thankfully, many common issues can be bypassed upfront if technical writers get ahead of the curve by creating projects with the translation process in mind. We have listed below a few guiding principles that, if utilized, allow for a much smoother translation experience.
Principle 1: Use CSS Over Inline Styling
In general, it is best practice to avoid inline styling in web design, and while MadCap Flare’s capabilities aren’t just limited to website generation, the same principle should be applied no matter the output.
Some key benefits in using CSS over inline styling include:
- A clear delineation between content and design
- Easy formatting revisions that are made in one place
- Short and tidy HTML
But what does this mean for translation?
Imagine that you have an English project that is being translated into Chinese. Several topics that the translator is working on have hard-coded, inline page breaks leftover from the source project dispersed throughout the text. However, because those page breaks match only to the English output and not to the newly translated Chinese (which is much shorter, character-wise), the Chinese output now has too much white space and is several pages longer than it needs to be.
Depending on the amount of manual breaks and how they were coded, fixing this error can be both costly and time-consuming. The solution – and a tip in preventing these issues from arising in the future – is to set page break settings in the stylesheet. This is best done during the project set-up phase, right when MadCap Flare projects are first constructed. In using this method, page breaks are automatic and based on the text itself rather than manually inserted in each topic. Likewise, all other formatting should be applied via the stylesheet for the smooth and clean transition of one language to another.
Principle 2: Create Editable Images
An often-overlooked aspect in project preparation is how images will affect the translation process.
Graphics frequently need design adjustments to accommodate for translation-related changes, such as the tweaking of different elements to fit newly translated text or the manipulation of layout to account for right-to-left reading orientation. Recreating these graphics from scratch can be tedious, frustrating, and likely outside of a project’s defined budget or scope. Instead it is much simpler to be proactive in readying your project for translation by creating images that can be easily manipulated without burning away hours.
A simple, hassle-free way to do this is to use MadCap Capture, a built-in image editing program that comes with any MadCap Flare subscription. It can be accessed through MadCap Flare by right-clicking on an image file in the Content Explorer and selecting “Edit with MadCap Capture” – or by simply opening the program itself via your taskbar. Elements are situated on a single layer but are not merged or “flatted,” thus making MadCap Capture a painless solution for creating and editing callouts and graphics.
Principle 3: Deliver an Error-Free Source Project (Or Close to It)
While it might be impossible to catch or solve every error, MadCap Flare files should be in the best shape possible before they are sent off for translation. Any problems that are present before translation will still be present after translation and thus replicated throughout each newly translated project. Following a standard QC checklist may help in finding and fixing common MadCap Flare errors.
Some ideas for a checklist might include:
- Building all necessary outputs and checking for missing and/or incorrect content, topics, pagination or styling
- Conducting a broken links and bookmarks report via the Analyzer tab
- Reviewing targets for correct conditions and variables
For instance, let’s say you have an English source project with a handful of broken snippet links. This project is in production for translation into five different languages and each has their own separate MadCap Flare project file. However, because the broken snippets were not fixed in the original source project and because the projects are essentially identical (except for any language differences), each of the five newly translated projects have the same exact error.
As it stands, none of these projects are technically sound. All five of the translated projects – as well as the English source project – need this error corrected. As you might have guessed, it would have been much more efficient to fix the errors in the original project instead of several separate ones.
Principle 4: Be Mindful of Conditions
Conditions are an integral part of MadCap Flare as they allow users to utilize the application’s single-sourcing features. By including or excluding specific pieces of content via conditions, you can insert a single topic in multiple targets to slightly differing effects.
However, as you know, translation from language to language isn’t always one to one and conditioned text in one language may not translate well into another. For example, if you condition the single letter “s” to make a word plural in one output and singular in another, this may not translate well due to differing pluralization rules. In order to prevent this, apply condition tags to a single word or – better yet – to a single sentence. Additionally, be sure that condition tags are set to either include or exclude in your target so that they are accurately translated
Conclusion:
Though MadCap Flare is a robust and user-friendly content management platform, systems and software can only go so far when preparing projects suitable for translation. Instead, the onus is on technical writers to help soften any bumps in the process.
Main image: © Adobe Stock
