MadCap Flare is a powerful authoring system with lots of helpful features. However, using these features without considering their consequences in translations can lead to errors that easily creep in and affect the translation process. A translation agency that is experienced in dealing with MadCap Flare projects is aware of the pitfalls and knows exactly what to look out for. Especially at the beginning of the cooperation with a translation agency, customers ask many questions. We have the answers.
Why use a language services provider (LSP) in the first place?
The main advantage of working with an LSP, such as MadTranslations, that is familiar with MadCap Flare is that they take a lot of work off the client's hands. The LSP knows exactly what to look for and detects possible problems immediately. Especially with grammatically complex languages, an experienced LSP knows which variables need to be flattened, which conditions work poorly or not at all in other languages and makes sure that image callouts are displayed correctly in other languages.
The LSP, equipped with technical translation services, can help optimize the source project for translation in such a way that DTP costs are minimized or even completely eliminated. These services are crucial for ensuring accuracy and consistency across multiple languages. After all, good preparation of a project can save a lot of money. Conversely, this means that projects that were not created with subsequent translation in mind often require a lot of time and money due to tedious post-processing. An LSP that checks translated targets before delivery eliminates the need for post-processing on the client's side. The LSP may also perform DTP work, which is especially important when the reading direction is changed, e.g. for Arabic or Hebrew.
In short: Clients that work with an experienced LSP can be sure that in the end everything will work smoothly and they don't have to worry about anything.
How do I start and what happens when I send a project to an LSP?
First of all, you need to send the right file type. To do this, zip the Flare project directly within MadCap Flare to create a *.flprjzip file and send it to the LSP. Specify the desired targets and target languages including the variant, such as Spanish for Spain. Ideally, you would inform the LSP about special features of your Flare project (e.g.: very complex conditions, global project linking, translatable graphics, etc.). The LSP's project manager first checks the Flare project for possible errors and corrects them before they can cause problems during a later stage of the translation workflow. Then the project manager extracts the files required for translation that are included in the desired targets, imports them into the translation environment and assigns the specific translators and reviewers.
After the translation and review step has been completed, the project manager performs a quality check, builds the targets in all requested languages and makes sure they are all displaying correctly, thus saving the client a lot of time and work.
How can I save the translations for future reuse?
You don't have to worry about that either. The LSP stores every translated sentence in a client-specific translation memory. We make these available to our customers at any time upon request.
How does it work if I have updates on my documents?
The procedure does not differ from the initial request: you send the zipped Flare project to the LSP and define the required targets and languages. The LSP uses the previously stored translations and determines the delta. This way you only need to pay for new or modified content in the Flare project, but you will always receive complete Flare projects in the respective target languages.
What kind of quality checks does a translation agency perform?
The LSP's project manager will check the translated content for a lot of different quality criteria, such as correct use of terminology, correct numbers, correctly placed tags, etc. After this, a final check is performed on all translated targets. This ensures that the translated text is displayed correctly.
Why are there separate projects for each language?
Translation tools always produce a translated copy of the source Flare project. This means that you will receive a separate Flare project for each target language. In general, the best approach is to store only one language in a Flare project. Multilingual Flare projects can become very difficult to manage and require a lot of attention. So the best practice is to store different languages in separate Flare projects. Furthermore, the translated projects can easily be used to create a multilingual online output by linking the translated versions in your main project's target.
What can I do to optimize my projects for translation and to eliminate errors as far as possible?
There are a number of things that you can consider as an author:
- Check for broken links and broken bookmarks before sending your Flare project to an LSP, since faulty links will be duplicated in the translated project.
- If you use global linking, child projects should be updated before they are sent to the LSP so that they have the latest content from the global project.
- Accept tracked changes, as they are difficult to translate.
- Complex conditions should be avoided, especially conditions where singular and plural are used in the same sentence. This does not work in every language. Instead, use a complete sentence for each condition to allow for grammatically correct sentences in the target language.
- Inline formatting should be avoided as far as possible, as it can lead to formatting issues. Formatting in stylesheets facilitates quick formatting changes across the entire project that your LSP might need to apply in the target language.
- Avoid absolute image positions so that images are automatically moved to the other side even if the reading direction is changed.
- Image callouts are best created in MadCap Capture since image text that has been created with this tool is easy to extract. Another ideal way to deal with image descriptions is to number the parts in graphics and to provide a key table below the graphic. This way, graphics don't require post-processing due to text expansion.
- UI strings should ideally be marked with dedicated spans to make them easy to identify.
- Product names and other non-translatables should be specified in variables so that changing them does not have a large impact on the number of words.
Please contact me at mmcdermott@madcapsoftware.com if you have any questions. We are happy to help.
