MadCap Flare is single-source documentation software with enormous potential when it comes to writing technical documents. The larger and more complex the projects are, the more challenging they will be when they’re subsequently translated – so there’s a lot for the language service provider to bear in mind in order to produce a high-quality translation with the right layout. These are the eight steps that make up the ideal workflow.
Firstly, it’s important to remember that the work done by the translators themselves is usually only a small part of the translation process. A high-quality translation, which in the best-case scenario would require no further adaptation on your part, is impossible without an expert project manager to prepare the project and export it once the translator is finished. And nowhere is that more true than with MadCap Flare projects. So if you work with a translation agency that doesn’t know its way around Flare, you’re likely to get some nasty surprises and may have to spend considerable time and effort fixing what they’ve done.
The agency needs to have plenty of experience and expertise – not to mention an eye for detail – in order to deliver projects where all targets work as they should and all content is translated correctly. The ideal workflow for translating MadCap Flare projects can be broken down into eight main steps.
1. Receiving and reviewing the file
The first step is to give the translation agency access to the project via its customer portal or an encrypted link, as Flare files are usually too large to be sent by e-mail. Once the project manager has received the file and all the relevant information (which targets need to be translated, deadline, languages required, special requirements etc.), they will open the file in Flare and examine the project closely. The aim is to find out whether there’s anything in the project that might cause problems in the translation process – and the list of potential sources of errors is long. Certain file formats might not be automatically exported for translation, so the project manager needs to export them manually. Targets can also cause problems, if they haven’t been defined correctly or if the file paths are too long. The project manager then builds the desired targets to test if they work correctly, and to establish whether graphics can be edited, i.e. whether they contain translatable text (this is the case if they were created using MadCap Capture).
2. Importing the project into MadCap Lingo
The next step involves MadCap Lingo, a CAT tool developed by MadCap which is very useful for extracting specific text from the required targets. The project manager imports the entire Flare project into Lingo and then selects the targets. Lingo then creates what’s known as an XLIFF bundle, which contains all the files required in order to subsequently translate all the target content. In Lingo the project manager also has to decide whether variables should be flattened or not. Flattening involves replacing content nodes with text, so the variables that should be flattened are those containing text which won’t be translated in the same way in the target language (e.g. if different inflections or compound nouns are involved).
3. Preparing the project in the CAT tool
The project manager then unzips the bundle created by Lingo and imports it into the CAT tool the translation agency uses. It is in fact possible to translate in Lingo, but as it doesn’t offer the full range of functionality required by larger agencies, such as server-based working, they will almost always use their CAT tool.
Preparing projects in the CAT tool is no different from the usual preparation process for other file formats. However, as Flare projects usually contain a very large number of files, the project manager needs to be very careful – especially when product updates only result in a small amount of new text to translate and most of the translation is already there. Another issue that can cause problems is tags: incorrectly inserted tags will lead to major XML errors, so that topics can no longer be opened or the Lingo project can’t be converted to a Flare project.
4. Translating the project
Once the project manager has created and prepared the project, the translator can begin their work. Bear in mind that Flare projects are usually more challenging and time-consuming to translate than other jobs. If the translator is working on software text or online help guides, for example, it can sometimes be hard to know what exactly they’re translating and where that text is located in the final document. So don’t be surprised if they have lots of questions, which the project manager will forward to you. And it’s a big help if reference files are available or if the translator can be given access to the software itself.
5. Reviewing the project in the CAT tool
Once the translation is finished, the project manager gets involved again. They carry out something called a quality assurance (QA) check, paying particular attention to tags and missing, additional or wrongly inserted spaces in Flare projects. Although these may seem relatively unimportant issues, they can have a big impact on the exported file.
6. Importing and checking the project in Lingo
Once the QA check has been carried out in the CAT tool, the project is ready to be exported. This involves importing the project back into the original Lingo project (see Step 2), where another QA check is carried out to identify any untranslated segments or missing/wrongly inserted tags. If everything is as it should be, the Flare project can be (re)created.
7. Checking the text and layout
Once the project manager has created the (new) Flare project, they will open it and build the translated targets. They then check the result to ensure all content has been translated (all links and references, headers and footers, search fields etc.) and that the layout works. If graphic texts were translated, the text boxes are often not big enough for the longer foreign-language text, so the project manager also has to make sure that these texts are displayed correctly and are all legible. Asian languages, and languages which are read from right to left, can be particularly challenging, so in these cases the finished target is usually sent back to the translator to be checked again.
8. Delivering the project
If everything looks good, the project is ready to be delivered. You will get it back the same way you sent it, and you can enjoy the peace of mind of a project where you have to do little to nothing more with it. Ultimately, this is the aim behind these eight steps taken by your translation agency: to lighten your workload.
You’ll probably have realized by now that what has taken you a few minutes to read will take hours, days, and usually weeks to deliver in practice. Translating MadCap Flare projects can be a very time-consuming process, depending on the scope and complexity of each project. Even just loading them in the software is a world away from working with Word files – so it pays to have a translation agency that knows what it’s doing.
Main image: © Adobe Stock
