I recently had the opportunity to participate in a panel discussion at MadWorld 2018, titled “Translation Panel: Learn How Your Organization Can Leverage MadCap Flare and MadCap Lingo”. Joining me on the panel were two other experts: Carl Christensen, Senior Software Engineer for MadCap Lingo, and Laura Dent, writer and localization expert.
We touched upon a range of topics focusing on translation, including translation tools, how to prepare for translation, and best practices when tasked with a translation project. The following is a compilation of the key takeaways from the panel:
When sending over your files for translation, stick to the source files
When it comes to sending content over for translation, it’s important to stick to the source as much as possible. Single-sourcing in translation can be a powerful tool, as it lets you translate once, and reuse many times across your content. When the source file is translated, it enables the author to create other output types using the translated files in the project, without the assistance of a translator. While translating the output files may seem like a quick solution, you run the risk of higher translation costs down the road.
For more information, read Carl Christensen's past blog post on why you should translate the source project instead of outputs.
How MadCap Lingo fits into the translation workflow
When an LSP receives a MadCap Flare project for the first time, a common initial reaction is to import all the files into their translation tool, translate the files, and export them. The reality is that in most Flare projects, it’s not necessary to translate every single file. For example, you may have files that you don’t want translated, or template files from when you first created the project.
From our experience as an LSP, we use MadCap Lingo primarily to put together a package that has everything a customer needs to build their output. The package is then sent to the translator. Once the translated files come back, MadCap Lingo can QA the content for any errors, such as missing tags or sections. In short, MadCap Lingo is great as a tool to filter content and maintain the project for any updates, streamlining the translation workflow from LSPs to translators.
On preparing your content for translation
When you’re preparing your content for translation, one major tip is to be concise in wording, and provide plenty of context for the translator. A single word or phrase may need extra contextual notes or screenshots, in order to provide an accurate translation. Providing context allows the translator to get a better understanding of the meaning and tone, no matter how brief the wording.
In addition, be aware of variables embedded in sentences, as they can introduce potential errors during the translation process. If you’re using MadCap Lingo, you have the option to select the variables that you want to flatten, sending only the exact content for translation. But regardless of the tool you’re using, it’s important to discuss with your translator beforehand to identify which variables need to be translated.
On common project delays and how to avoid them
During the translation process, there’s a number of issues that could result in delays in your project.
Administrative Delays. Oftentimes, companies and organizations need to undergo a vendor review process before moving forward with a translation vendor. It’s a good idea to check if there’s a pre-approved vendor that you’re mandated to work with, before going through the process of obtaining quotes and estimates.
Client Review Process. Once the translation is scheduled to be completed, is there someone in place that will validate the translation from your end? Ideally, the final output is generated once the content has been validated on the customer side, and it is approved to compile into the final Flare project or file type. Planning ahead with your translator on how edits and comments are reviewed can save weeks of time, and facilitate final delivery of content.
Project Updates. It’s inevitable that changes will occur to the source project during the translation process. However, making a decision on how necessary those changes will be before a particular release can determine when the project will be completed.
Wordsmithing. After the translation is completed, it’s recommended that you avoid tweaking the source content unless absolutely necessary. Once the translations are committed to a translation memory, even a few edits to the source text could change the tone of the content. Depending on how much is changed, the edit could result in a fuzzy or zero match, resulting in essentially a retranslation.
How to perform a check on quality assurance
Unless you have an in-country subject matter expert on hand to review content, verifying the quality of the final translated result can be a case of “he said, she said”. As far as objective measures of quality assurance, your translation tool can include a number of features and checks to help you find and fix issues. For MadCap Lingo users, here’s an example of the reports included with MadCap Lingo:
Mismatching numbers in source and target. This report shows segments where numerals are not the same in the source and target segments.
Inconsistency in translation of repeated source segments. This report shows segments where two identical source segments do not have identical translations.
Large variation in size of source and target segments. This report shows segments where either the source or target differ in length by more than the defined threshold.
For more information, take a look at the topic page on Running Quality Assurance Reports with MadCap Lingo.
I hope you find these takeaways useful, and thanks to everyone that joined us for the panel. Feel free to leave a comment below, or shoot me an email at mmcdermott@madcapsoftware.com for any questions.
