How to make conditions in MadCap Flare suitable for translation

MadCap Flare gives technical writers lots of options when producing their texts, and conditions are one of them. Here are 6 tips for using conditions so that they’ll be suitable for translation later on, which will help you avoid unnecessary costs and incorrect translations.

MadCap Flare is single-source software, and one of its key features is conditions. They allow you to include or exclude content, so for example you can determine which text should appear in which output format or document: Information A can be in Manual 1, while Information B can be in Manual 2. Conditions are extremely useful and allow you to do lots of different things. But this can cause problems for the subsequent translation process, primarily when conditions are created which don’t work properly in other languages or when certain basic rules aren’t followed. As a result, you might end up paying more than you need to and having to fix bad translations.

Conditions in the translation process

In the source language, conditions aren’t usually a problem. It’s easy for the writer of the documentation, working in their native language, to ensure that each different version makes sense – even if a sentence contains multiple conditions. But they often don’t think about the translation when creating these conditions. Many sentences are “overconditioned”, so that (in the worst case scenario) it isn’t possible to get every version to make sense in the target language, despite the translator’s best efforts. A sentence needs to make sense both with and without the text in the condition(s), and this can make things extremely difficult in languages with different rules governing word order.

The challenge of using English as a source language

A good example to highlight the problems conditions can cause is source texts in English. Grammatically speaking, English is simpler than lots of other languages – for instance, to form plurals you usually just need to add an “s”. Conditions make this easy to do, and in the source text everything can work beautifully, but the problem comes when the text is translated into languages with more complex grammar, such as Russian. It may be that more than one part of the sentence needs to be changed, and when the various cases are taken into account, the translator might end up having to rewrite the whole sentence. When that happens, it’s highly likely that the parts of the sentence won’t fit together and some of the versions no longer work properly. So we recommend writing the sentence so that it can be translated as one unit. In short:

Less is more – the simpler the better

The more conditions a sentence contains, the harder it will be to translate and the more likely you are to get mistakes and clumsy translations. Translators familiar with Flare projects are aware of the challenges and will do everything they can (often showing seriously impressive creativity) to produce target-language sentences that make sense. But there are conditions that even the best translator can’t translate, especially if they’re combined with variables. A good translation agency will let you know when this is the case and will recommend that you rewrite particularly difficult sentences – ideally, they’ll sit down with you to discuss the best way to resolve the situation. As a general rule, it’s a good idea to keep conditions as simple as possible and not to use them on individual letters. There’s every chance that unnecessarily complex conditions will result in mistranslations, especially if you’re working with an agency or translators who aren’t familiar with the features of MadCap Flare. So that’s our next top tip:

Just a tick... or is it? 

Before sending a project to the translation agency, you should check that all conditions have been created correctly. That’s our third top tip:

It’s all too easy to create a condition and then forget about the associated settings in the target. When you’re under pressure to release a text, hiding conditions is often a long way down your priority list and doesn’t get done until the text is about to be published. Sending the Flare project to the translation agency like that can result in a considerably higher translation word count than necessary – if the translation word count seems suspiciously high, this is often because the options to exclude content haven’t been ticked. 

By “ticked”, we mean that you can choose which conditions are required for each target, so you can include or exclude them in the output files as required. Unfortunately it’s not enough to simply ignore it and carry on without ticking the relevant option. Which leads us to our fourth top tip:

If you tick the “Include” option for a condition, the condition will be included in the text to be translated. However, if the option isn’t ticked, the condition will still be included for translation if it’s linked with a topic somewhere in the target to be translated. This can sometimes be difficult to see at first glance, especially with larger online help guides. So you should also tick the “Exclude” option if you don’t need a condition in a target, in order to avoid unpleasant surprises in terms when the agency tells you the word count.

How carefully written texts can save you money in translation

We have two more top tips to help you avoid paying more than you need for your translations.

Internal comments are widely used, but you should think carefully before using conditions for them in continuous text. If you forget to hide the relevant conditions, there’s a real risk that the internal comments will be translated (so you’ll pay more than you should), and they could even end up being published in the final manual as well. So we recommend using Flare’s annotations feature instead, which also allows you to search for topics which contain comments via the analysis. 

And last but not least:

Whether or not conditions need to be used for product names depends on what you want. If you want to use different product names in the targets, variables with different definitions are another useful option: for instance, in Manual A you can use the version with Definition 1 and in Manual B you can use the version with Definition 2. This option also saves you money, as when product names are changed you only need to update the name in the variable sets. That way, the new product name is only translated once in the variable set rather than hundreds of times in the continuous text.

Main image: © Adobe Stock