For anyone getting ready to start translating their Flare projects, it can seem like a daunting task. It may have you asking a lot questions like: How does the translation process work? Do I need to use Lingo? What does a Flare translation project look like? Is my current Flare project set-up well for translation? Do I have to become an expert in publishing foreign language documents?
Morningside has been assisting clients with their Flare translation projects for over 15 years, and we understand all the particulars of the process. Here are some quick answers to help guide your initial steps:
How does the translation process work?
This will depend on the vendor you use for translation. For example, if you work with Morningside, you can send us your Flare project and let us know which targets you want to translate and which languages are required. We will determine which files are used by those targets and then translate those files directly. After translation, we will build the translated targets and have the outputs undergo Linguistic Quality Assurance (LQA), to make sure that everything looks correct in context. Any issues will be resolved in the localized Flare files, and the final outputs will be built. We can deliver the localized Flare projects with fully finalized outputs that meet every specification and requirement you give us.
Note: Some vendors who don’t have localization engineers well-versed in Flare may not be able to build outputs or translate the Flare files directly.
Do I need to use Lingo?
No. While Lingo was originally created to process Flare projects for translation, it is entirely optional. It essentially serves to (1) determine which files need translation and (2) process those files for translation, two things that experienced vendors can already do without Lingo. Lingo actually adds an extra step in the process that we don’t need – although we can use it if requested to do so.
That being said, Lingo can be useful in the following situations:
- If you are working with a translation provider who doesn’t know Flare very well, Lingo allows them to still supply translations. The provider can translate XLFs exported from Lingo and hand them back to you, so that you can finish up the foreign language publishing work in Flare yourself.
- Lingo allows the client to view the contents of their Translation Memory (TM). You can create an empty TM in Lingo and fill it by importing TMX files that you’ve received from your translation provider. Then, the TM contents can be viewed, filtered, and searched.
What does a translated Flare project look like?
The best approach is to maintain a complete copy of the original Flare project in each language. The file naming convention and folder structure should be identical, so that no re-linking work is needed. All translated files should be completely translated, so you don’t have to keep track of or worry about translation gaps inside the files.
Is my current Flare project set-up well for translation?
Most of our clients author their Flare projects in English, and English is an extremely flexible language. Combine that with the flexibility and cool single-sourcing features in Flare, and you can get some very interesting and creative authoring! But some of that authoring is not ideal for translation into other languages. Here are some quick tips:
- Don’t use common nouns inside of inline snippets or variables.
By “common nouns”, we essentially mean the opposite of proper nouns. Common nouns are translated, such as “configuration”, “settings”, or “application.” In many languages, these common nouns may need to change spelling based on their part of speech, or the gender of the noun may have an impact on the words around it. It’s best to limit inline snippets or variables (anything that appears inside a larger sentence) to proper nouns only, or other things like phone numbers, emails, URLs or measurements. - Limit the use of inline conditional tags.
Conditional tags can be very helpful, but overusing them inside a sentence can make the text hard to decipher. Try not to use more than two conditional phrases inside a sentence. Also, try to use conditional tags on self-contained phrases that don’t impact the rest of the sentence. For example, conditional tags are fine on a prepositional phrase such as “on the Settings page.” - For images with callouts, use MadCap Capture or use a table legend underneath the image.
Localizing image text the traditional way － by typing out the text in Word, translating it, then pasting the translations into Photoshop or Illustrator－ can definitely be time-consuming. The first alternative is to add the text callouts using MadCap Capture. The callouts in MadCap Capture can very easily be translated with our translation tool, bypassing the usual copy/paste process and making image work much more efficient. The second alternative is to add numbered callouts to the image and then supply the legend for those callouts in the Flare topic itself. Using that approach, the legend can be translated with our usual process and we can skip all image work entirely. - Design tables with text expansion in mind.
Most languages expand 30-40%, compared to the original English text. And, many languages, especially German and Russian, have longer words on average than in English. Making sure that there is sufficient room in your table columns to fit longer words and more text is always a benefit. Having that extra room for expansion will mean less work trying to get the translated text to fit. - Set page-breaking styles in the stylesheet and avoid forcing page breaks.
Create rules for when page breaks are not allowed in the stylesheet, based on structural elements. Don’t only set these rules in specific locations in the English. The text flow can change dramatically in translation due to the text expansion mentioned above. So, if you are concerned about a page break on page 15 in English, that may not be a problem in Spanish – but Spanish might have an issue you didn’t foresee on page 17. Setting global rules based on structure can help reduce page-breaking issues in translation. Similarly, forcing page breaks in certain locations in English means that we are likely to see large empty spaces in weird places in translation. Instead of forcing page breaks where you want to see them, look at the situation differently, and AVOID page breaks where you don’t want them. For example, if you are tempted to add a page break before a paragraph that leads into a bulleted list to keep them from getting split up, instead add a “page-break-after: avoid” to that paragraph, to serve as a “Keep with Next” effect.
It’s important to keep in mind that the above suggestions are tips for efficiency in translation. We understand that sometimes the English project requirements simply do not permit you to follow all those guidelines – and that’s okay. A knowledgeable translation service provider can translate any project, regardless of how well they follow the list above. Morningside, for example, offers the optional service of prepping your English Flare project for translation, then delivering it back to you, to help optimize the translation process before it starts.
Do I have to become an expert in publishing translated documents?
Not at all! That’s the beauty of a full-service Flare translation provider. You shouldn’t have to worry about which fonts are best for Traditional Chinese, how to fit an extra-long German word in a tight spot, where to insert line breaks for Thai, or how Right-to-Left languages like Arabic are supposed to appear. A good translation partner can produce PDFs ready to print or online layouts ready to publish.
Clients have been seeking Morningside’s expertise for their Flare translation needs for nearly two decades because they know we can simplify their process. So Contact Us to let us know what we can do to optimize your process today.