A common question we see from documentation teams and technical writers revolves around a very key fundamental issue: “Should I translate my MadCap Flare project, or can I translate my output files, such as a PDF or HTML5 website, instead?”

Blog-InPostImage-TranslateFlareFiles

While translating the output files may alleviate the worry of filtering out the variety of project files (such as snippets, page layout files, etc.) or conditioned strings, this method is a short-term solution and can introduce much higher translation costs down the road. We always recommend the source project is translated to avoid these cost overruns.

Additionally, here are our top five reasons why you should be translating your MadCap Flare projects instead of your output files:

1. Search Functionality

Search is a critical component to your online content — it is how users find the content they need. When Flare builds an HTML5 target, there are a number of search files that are compiled during the build to enable the search functionality. The words get stemmed and put in an indexed file, for instance.

When translating just the output files, any JavaScript files in the data folder would need to be parsed and translated without context of where each word is located in the content. Additionally, some custom controls in the content may also need special handling, adding to the complexity of the task.

2. Manual Sorting

If the source project contains an index or glossary, the alphabetic sorting and any custom sorting of these elements will need to be done manually. In this case, it’s preferred to translate the source Flare project, as these elements are sorted automatically with no manual intervention in the output files. This can save hours of unnecessary time, which may otherwise be billed by your translation partner.

3. Maintaining a Single Source

There are two key reasons why maintaining a single translated source project is beneficial. One is the ability to publish new outputs. Typically the file names in a translated project will remain in English, or the source language. This enables the author of the source project to create other output types using the translated files in the project without the assistance of a translator.

The second is republishing content with minor updates. With a translated project, making minor adjustments to addresses or product names for instance, is easy. With just the translated output, it would require manual manipulation and republishing of the output files.

4. File Maintenance

Having a single project for each language enables the author to maintain many outputs for each language pair. When translating the output files, you will be left with many different files for each output. This can become a maintenance challenge for updates and publishing.

5. Precise File Translation

One of the key advantages of translating the Flare project stems from Flare’s integration with MadCap Lingo. MadCap Lingo will ensure that only the necessary files are being translated, as it identifies the strings and files that need to be translated per output. Lingo is designed to tell the translator exactly which files contain translation candidates relevant to a given output. In short, the guesswork is taken out of what needs to be translated, mitigating against any potential errors or pitfalls.

In Summary

As you can see, there are a number of reasons to translate your projects instead of the output files produced from your project. When you translate your Flare project, you ensure the overall integrity of the project, you avoid potential workflow and maintenance challenges, and you reduce your overall translation costs.

So the next time a team member or manager asks about translating that PDF guide or website, you can show off your knowledge armed with at least five reasons why a Flare project translation is the smartest choice.

About The Author

Carl Christensen

About Carl Christensen

Carl Christensen is a Senior Software Engineer at MadCap Software, with over six years of experience in developing natural language processing software. He heads the development team for MadCap Lingo and aides in localization considerations and features in MadCap Flare. Since joining MadCap in 2012, he has overseen multiple releases of Lingo and presented at several conferences on the subject of language and translation.

Last Modified: March 9, 2016

This entry was posted in MadCap Flare, MadCap Lingo, Translation. Bookmark the permalink.

Comments

  • Thomas Bro-Rasmussen September 15, 2017 at 11:04 AM

    I think you should have had two more reasons:
    1) It is close to impossible to maintain a proper Translation Memory if you translated the output. In particular PDF! So the entire financial benefit of repeated translation iterations from the same project is sort of lost.
    which lead to
    2) It is excruciating expensive in both the short and long run to translate into any output. Just think of the repeated translations you have to make on repeated text (snippets in Flare).
    Just thinking

Have Something to Say?

Your email address will not be published. Required fields are marked *