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?”
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.
