Translation agencies aren’t always familiar with documentation in MadCap Flare, which means technical editors can face problems when it comes to getting their texts translated. We outline the most common problems and their causes, and explain what you can do to avoid them.
MadCap Flare is a very powerful authoring tool. A translation agency will ideally have the expertise to handle Flare projects, so that technical editors get both a high-quality translation and files that are easy to open in Flare and can be used to compile the targets – but not every agency is in that position.
Problem 1: The agency or the translators don’t know what the various tags mean or how to use them correctly.
Tags are a great example of how seemingly small details can have a big impact. Flare is XML-based, which means the structure information is contained in tags. And although CAT tools filter out many of the tags so that the translator doesn’t see them, the files for translation still contain various inline tags which can’t just be ignored when translating.
If the agency’s translators (or its project managers) don’t know what each tag means, you won’t just get mistranslations – it will also be impossible to open the topics in question. Tags for simple bold text or hyperlinks are unlikely to be a problem, but the translator really needs to know what they’re doing when the text contains variables and conditions. Sometimes all it takes is one missing or wrongly positioned tag to cause an XML error, resulting in problems that could easily have been resolved with the relevant Flare and XML expertise.
Problem 2: End customers give feedback that some sentences don’t make sense.
Sentences often contain multiple conditions. This might work in the source language – particularly if it’s English – but it usually causes problems in the target languages, and in many cases the problems go unnoticed until the end customer points out that some sentences in the documentation don’t make sense. If it looks like parts of sentences have been inserted in the wrong place, multiple conditions are likely to be the reason.
For the translator, the challenge isn’t just recognizing the condition tags, but also working out how to phrase the sentence so that the conditions work correctly in the target language. Sometimes it simply won’t be possible to do that for all the conditions, for example if the sentence includes singular and plural versions of nouns, and the result is a translation with completely garbled sentences. A translation agency with Flare expertise will know how to handle conditions, and their translators will do their best to phrase the translation so that all the conditions are covered. But if this proves impossible, despite their best efforts, the project manager will be on hand to consult with the client and explain how to create conditions that are more suitable for translation.
Problem 3: The translation agency delivers unusable files.
This is often caused by the agency using the wrong import filters in the CAT tool, which can lead to incorrect coding in the translated files and make them unusable. Flare projects don’t just contain HTML files – there are also snippets, variables, glossaries, index files etc. with specific endings for Flare. So the agency needs to use exactly the right file filters in order for all translatable content to be “extracted” correctly.
Problem 4: You realize that too much or – even worse – too little has been translated.
A common problem is that the translation agency doesn’t know which of the many topics and other files in a Flare project are required in order to correctly compile the targets requested by the client. That may mean too much or too little is translated: the former is bad for the budget, and the latter is even worse as it will result in source-language content in the target-language documentation. Even if the agency uses MadCap Lingo, sometimes too few or too many files are extracted for translation – index files are often missing in Lingo, or it may contain all Flare glossaries even though they only contain example entries specifically for Flare. The settings for conditions may also have been accidentally changed since the previous version of the documentation was translated, which can lead to noticeable increases in the word count. That’s where a switched-on project manager who looks carefully at any anomalies and asks the client for clarification will make a big difference.
Problem 5: You realize that the layout doesn’t work properly in your target.
PDF targets in particular allow a visually attractive layout to be designed, but the technical editors producing them sometimes aren’t aware (or forget) that translations can end up being longer than the original text. That means the target-language text may no longer fit in the available space, or the formatting ends up being all over the place – and you as the client may not notice the problem until you’re compiling the files in a hurry shortly before the release date. A translation agency which has no experience with Flare projects, and which may not even have the software, won’t be aware of this issue and won’t be able to fix it, simply because it can’t build or check the targets before delivering the project.
Problem 6: You get translated XLIFF files back, but you can’t edit them.
This problem can occur when the technical editors work with MadCap Lingo and send XLIFF files to the translation agency. If the agency then uses a CAT tool which isn’t capable of producing “clean” XLIFF files, the technical editors won’t be able to import the translated files back into Lingo. So the agency should make sure it uses the right CAT tool for these projects, and ideally should offer to run a practice project in advance.
The solution?
Right now you might be thinking that this post is heavy on problems and light on solutions. Don’t worry – it’s not all bad! There’s a simple way to resolve all these problems (and more): make sure that your translation agency has expertise with Flare and is constantly expanding and enhancing its knowledge of the software. If your agency knows what to look out for when working with Flare, you won’t need to work in Lingo or spend lots of time compiling targets, and you can rest assured that your Flare projects will result in correctly translated documentation that does everything it’s supposed to do. It’s as easy as that! You save time and stress, plus you can work together with your contact person to find the right solutions for you and continuously optimize the translation process.
Main image: © Adobe Stock