Automated and agile workflows – which technical editors wouldn’t want that? That used to be wishful thinking for those writing their documentation in MadCap Flare. But things have changed. Find out how you can implement automated and agile workflows when translating Flare projects.
Automation is a big talking point in translation, and that includes translation of Flare projects. Technical editors writing their documentation in Flare have previously faced two main challenges:
To get a Flare project translated properly, the best method was to send the entire Flare project to the translation agency. But that involved lots of manual steps:
Not only is this time-consuming and liable to produce errors – most of all it eliminates any chance of an agile translation process. The translators can’t start working until the source texts have been fully prepared, so quick turnarounds are impossible.
To find out exactly how much the project would cost to translate, the entire Flare project needed to be imported into the translation tool and analysed – after all, no technical editor wants to spend time making lists about which topics have already been translated and which haven’t. Most Flare projects are pretty big, which means each stage in the process often takes a very long time and technical editors waste countless hours waiting for the agency to get back to them. Once they finally supply the quote, there’s usually an approval process to go through first, which can also take a while, so by the time the translators finally begin their work, the deadline is looming. And of course a tight deadline isn’t helpful when it comes to producing high-quality translations.
There are solutions for both of these time killers: automated workflows which enable agile working methods in the creation of technical documents and the subsequent translation process.
As soon as a technical editor finishes a section in their Flare project which they’d like to get translated, they simply click on a button to set the translation process in motion. The Flare project is automatically synchronized with an environment monitored by the translation agency’s CAT tool, and the translation workflow begins. The translated files are then sent back the same way. So while one part of the document is being translated, the team of technical editors can work on other parts of the document.
This method bypasses all the manual steps described above: no zipping Flare projects, no uploading files to a portal or sending them by e-mail, no selecting targets etc. That saves technical editors a huge amount of time, and the overall process becomes much less susceptible to errors – when selecting targets manually, all too often targets which aren’t needed end up getting translated, and technical editors themselves are surprised by the content they find has been translated in targets (and by the extra, unnecessary amount their company has to pay). Another major plus point is that the translated Flare projects remain in the same, controlled environment from which the targets can then be built. This is important when specific fonts or user-defined scripts have been incorporated into a Flare project.
You need sufficient lead time to enable agile and time-saving workflows like these. The following questions need to be resolved:
This depends on the software used to create the technical documentation. If you already have a GIT repository, for example, it makes sense to work with that. If you’re working in MadCap Central, you can continue to connect to those processes. And if you don’t use either of those, you can create other interfaces (e.g. monitored folders). Essentially, you need to look at the status quo to decide on the best way to proceed.
Versioning is especially important when working with interfaces like these, as the process is extremely flexible and multiple parties can work on the files. That can make it harder to track who made which changes and when, so it’s even more important to get clarity on this issue in advance.
The ideal scenario described above assumes that the translation agency doesn’t need to produce quotes and that the technical editors can get approval for the budget. If translations are ordered directly, rather than requiring quotes, the question is how to keep track of what you’re spending on translations. This is fairly easy if you use a “cost cap”: a framework agreement specifies the monthly budget available for translations, and you’re notified when you get close to that limit. You then have time to postpone translations until the following month or adjust the budget to suit the individual circumstances, so you can stay on top of your translation costs even without individual quotes for projects.
Effective automated workflows can only be established following thorough, in-depth discussions between a client and a translation agency. Each client and each Flare project will have their own requirements, and these have to be taken into account when setting up integrated workflows for automation. If you have the right partner and take a step-by-step approach, you’ll find the solution you’re looking for. So before making big decisions, let alone big investments, in this area, it’s a good idea to familiarize yourself with what localization experts at a translation agency can do.
Main image: © Adobe Stock