Tackling localization issues in Flare

If you are familiar with Madcap Flare, you will know that it is a popular tool for authoring and managing complex projects, thanks to its simple approach to content reuse and multi-format publishing.

What you may not know, however, is that when paired with its companion app Lingo, Flare can also handle the localization (translation and adaptation to a different market) of content into virtually any language.

Localizing a Flare project, though, is not as straightforward as translating a simple text document, and producing an output as seamlessly close to the original as possible takes some finesse. In this article, we are going to share a few tips for tackling common issues in the localization of Flare projects.

A variable diet

A Flare variable is a reusable piece of content, like a product name or telephone number, which can be quickly inserted into multiple places across a document. Variables are extremely useful to ensure consistency in technical texts, and using them correctly can make your translation process easier and cheaper, and produce higher-quality results.

Imagine, for example, you are writing an instruction manual for a piece of software, and you need to make sure that the terms related to the user interface match the ones in the localized software. A dedicated UI variable set can act as an internal glossary. Translators receive a list of UI terms and their relevant translations and use it to fill in the variable set. Then, Flare automatically “injects” each translated variable in all the sentences where the original variable was used.

The use of variables does have to be thought out carefully, though. In some languages, words like nouns or adjectives vary slightly depending on their function in the phrase.

Let’s say we are writing instructions for the use of an electronic device and we want to use “red button” as a variable. Take a look at how the words change when we translate these two sentences into German:

Sentence 1

English: The red button activates the device.
German: Der rote Knopf aktiviert das Gerät.

Sentence 2

English: Press the red button again to turn off the device.
German: Drücken Sie den roten Knopf erneut, um das Gerät auszuschalten.

In the first case, red button is the subject of the phrase, and it translates into German to rote Knopf. However, in the second sentence, it becomes roten Knopf, since the red button is the object in the sentence.

Using these words as a variable will not allow a translator to formulate the phrase correctly, so what do we do to fix this issue?

The best approach is to entrust the writing of your technical documentation to a company with experience in the localization of Flare content. If that is not possible, a localization engineer will need to analyse the source for any variables that might cause trouble during the translation, and “flatten” them in Lingo, meaning they will become plain text that the translator will be able to manipulate as needed.

Lay it all out

One of the most common problems when publishing a Flare project that has been translated is making the print layout appear as close as possible to the original (source) language. Translated (target) text can vary in length by as much as 30% when compared to the source.

A common mistake is designing your layout around the English without planning for future translations. For example, using page breaks or empty lines to define where the text will be positioned on the page. This can be especially tricky for printable brochures where the number of final pages has to be exact.

While planning ahead is always the best option, localization specialists can usually remedy any shortcomings by editing the layout in the translated Flare target . This can involve resizing the page margins, reducing the font size, or resizing the graphics to make more room for text. It is important to consider that this work will take extra time and delay the publishing, so always consult a localization specialist before finalising your English text if you can.

Graphic detail

Just like your body text, the text contained in graphics can also expand when translated, which can become particularly difficult in the case of complex diagrams. The problem with graphics is the extra text cannot just flow onto the next page, and the font size can only be reduced up to a certain point before it becomes too small to read.

If you’re still at the planning stage, our advice is to keep the amount of text in graphics as low as possible.

 If you’re working on localizing a document with graphics that already have embedded text, consider editing the graphic by replacing the original text with numbers, and adding the translated text as a key in the Flare document text.

When it comes to complex diagrams, if your text boxes are too small for the translation, try to use a font that is easier to read when smaller (Sans Serif fonts are best for this), but if that is not enough, recreating the diagram with a software such as Visio might be the best option, and it will allow you to save an editable format that can be translated directly in the future.

Fonts matter

Finally, let’s talk about fonts. Anyone in the publishing industry knows it: a font can give style and character (pun absolutely intended) to your documents. Lots of big companies even have their own custom typeface that allows people to immediately recognise their brand.

The problem is not all fonts are created equal. When writing a document that is going to be translated, ask yourself: does the font I intend to use have characters for the languages I am going to translate into? If it doesn’t, you could end up with something like this:

All the characters in red are not present in the original font, so they are automatically replaced with a different font.

While it would be best to choose a font that has all the characters you are going to need, this is not always possible, especially if you plan to translate into languages that use a completely different alphabet.

The good news is that if your font is defined in the CSS, replacing it is quick and easy. Simply open the stylesheet in a text editor, and perform a search and replace for the font name, paying attention to use single quotes if your new font has a name with more than one word.

At 3di we have extensive experience of writing and localizing a variety of software and technical documentation. Whether you plan on working with us from the very creation of your content, or you have content that you need help localizing, we can find a solution that is right for you. So why not get in contact with us here?