Review localization workflow
In the pre-analysis phase, we established and outlined a full localization workflow. Now it’s time to revisit the workflow and put theory into practice. It is our experience that we need a full localization workflow diagram to align the expectations of all the involved stakeholders. The diagram is used as the backbone for our processes and tasks, but is also used to identify bottlenecks and areas where we can improve the process.
Before you send out your Flare projects for translation, it’s a very good idea to supply your translators with term definitions and prepare a bilingual termbase. It is crucial that the translators know the company/product terminology in order to make high quality translations. If you have used the Flare glossary feature, the term definitions are already there!
No matter which CAT (Computer-Aided Translation) tool you are using, you need a bilingual termbase. The CAT tool can then look up the approved translation of the source term – in some tools, you can even make a glossary consistency check. If you already have a termbase with approved translations, then you can import the termbase into Lingo (or other tools). A termbase is an indispensable help for a translator, so don’t miss this step out!
Prepare Translation Memory
A Translation Memory saves the source and target segments (word, phrase or sentence) one by one in a database. This means that the CAT tool can look up in the TM to find exact matches (100-101% match) or fuzzy matches (99% match and below). The CAT tools can also pre-translate using the TM matches according to your settings. Typically, a translator will accept 100-101% matches and may also include fuzzy matches. The fuzzy matches do need to be reviewed, of course.
W2U helps our clients review any existing TMs or build new TMs. Existing TMs can be imported into Lingo using the TMX (Translation Memory eXchange) format. This will give the translator a head start with the project, because many translations have already been approved.
If we start from scratch, we let the CAT tool build the TM for us. Every segment we commit goes into the TM and can be used by this or other translators in the future.
Using TM is paramount to be able to translate large volumes of data. Also, the reusability nature of a TM ensures that we have consistency in the translations throughout a documentation set.
Export Flare projects
Before you send a Flare project for translation, please consider whether the entire project should be translated. If not, Flare has a really powerful export function where we can export portions of a project (by target, by conditions, etc.). The result is a fully functional Flare project that the translator can work on – and even build himself if he has Flare.
Monitor translation status
The communication channel to the translation bureau (or other external translators) must always be open. The translator needs to have access to experts who can answer domain-specific questions about the subject matter.
On the technical side, W2U recommends that we make spot tests throughout the translation project. We may find errors/misunderstandings early in the process which means that we can correct them early. So instead of having a huge QA process at the end, we take it bit by bit along the way. With large translation projects, the saying is “an elephant must be eaten in small portions”.
Monitoring the translation status is also very important to keep track of the project. With the topic based nature of Flare, this actually becomes easier because we now also have a topic count (apart from the standard word count).
Import translated projects
When the entire translation has been approved by the translators and language reviewers, we can import the Lingo translation package or the individual XML/HTML files (if Lingo is not being used).
In Lingo, we can now export to Flare and test the final localized output!
Quality assurance (QA) is not only limited to the source language. All languages have special rules and they need to be complied with to get a high quality documentation output. W2U has built a QA checklist with a number of points to be checked. When all points are approved, we can move on to the final build.
Build and publish localized projects
YES – we can now finally build our localized versions of the documentation. In Flare, we typically have more than one output, so we need to build them all and make a final visual inspection. First we build a local copy for visual inspection, then we publish to the final destinations (website, development server, marketing server, etc.).
If you have many outputs in many languages, your Localization Manager will surely ask for some automation. Luckily, this is all available directly in Flare. In the Flare UI, we have the batch target feature which allows us to build and publish many outputs in one project. However, the most powerful automation feature is the command line syntax in Flare. Using a simple syntax, you can compile as many Flare projects as you want in one operation – and schedule the compilation to run at night. In the morning, you have your finished output – ready for use.