Conditional Statements are no easy reads.
Sometimes we come across a translation project that requires a different approach than usual and Translating Conditional Statements is one of those projects and this is where certified Localization Project Management is essential. Like the one we had recently collaborating with our HR client on a set of Word templates used to communicate pension benefits. These templates make use of the Mail Merge feature in Word that enables the company to send out custom letters to their employees (or retirees/terminated employees) based on a set of variable fields. Typically, those variable fields are very simple, such as the name of the person, date of birth and other variables like age, payout amounts, etc. These are things that usually can be localized within the system and are picked up with most translation processing software (CAT tools). But these templates also contained conditional information that included variable text depending on conditions such as the division they were working for, whether or not the person was married, whether the person had retired or had been terminated or still employed, whether the person was salaried or not, etc.
Depending on the conditions set for each person, the letter can include information that is entirely different. Because of the complexity of these letters and variable data, translating conditional statements directly in the mail merge fields made more sense than translating the static output of 150 – 200 letter kits by translating and updating each kit with variable data (read more on the cost of updating translated documents). We see the same problem in healthcare translations with healthcare related materials that are customized for each patient member.
CAT Tools must have missed the memo on Translating Conditional Statements in mail merge
In researching about translating conditional statements in mail merge form fields, I came up pretty much blank on methods to process conditional statements using CAT software. After many settings, including processing hidden fields and pretty much every possible process option in SDL Studio, my wish was to simply extract the field codes as a whole, including the formulas. At least then, we could integrate our Translation Memory and Termbase that we had created for this particular company in the workflow. However, Studio seems to only process data that is activated, not any of the conditional text that is hidden. Converting to XML only helped so much as to getting the content processed, but it was broken up into so many segments that it would have been impossible for the translator to see everything in context. Another suggestion on a forum was to process in the old Trados program, as it tends to just simply process everything but the result was the same.
Surely, you can’t be serious that no one has ever tried to translate Mail Merge Fields using CAT Tools before?
It’s always surprising to see that, despite almost 20 years of serious technological advancements in CAT technology, every now and then you end up in a situation that seemingly has never been explored before (read our recent discovery about the use of XLIFF in SDL Studio or our findings on incompatibilities between CAT tools). Surely, we are not the only ones that have come across mail merge documents that need to be translated? Or is everyone just translating thousands of repetitive letters with each different variable outputs? Perhaps we reached a technical limit here, but it was surprising to see the lack of interest on forums on this subject.
Sometimes you just have to go old school in Translating Conditional Statements
Technological advancements couldn’t help me on this one. Sometimes you can go blind on trying every possible technological solution before reaching the conclusion, that maybe it’s time to go old school again and just translate directly in Word. However, for that we had to give up a lot of control. First of all, you lose the bilingual nature of the translation environment. There was not going to be any Translation Memory integration for leverage and consistency, and since we had built an extensive Termbase with approved terminology, we would have to resort to manual lookup.
On the other hand, working directly in Word did give us a much better overview of the context of each conditional statement, rather than a broken segmented view. And since we work with regular team members on these jobs for years, our team is able to provide much more continuity without having to resort to a lot of referencing of legacy materials. Being able to work directly in Word also gave us much flexibility in setting up the document for translation. Luckily you are able to highlight form fields to give the translator some visual reference as to what to translate or not. Also, in highlighting text specifically for translation gave us at least the opportunity to extract the text (by selecting text based on finding highlighted text with a particular text color) to get a sense of word count (although we decided to bill hourly) and to run that text against the verification tool in Studio for missing terminology.
Preparing Conditional Statements for translation
Differences in the way variable data is presented between different countries and languages such as dates, currency, and even decimal and thousand separators, can be enough to give most system developers a headache. However, conditionals can be a true grammatical nightmare. I’m always reminded by our Korean language expert about the difficulties of translating conditional statements into Korean, as their sentence structure looks nothing like the English counterpart. Even something as simple as referring to fractions works entirely different in Korean and requires a reorder of the conditional formula.
To get into a detailed overview of how conditional statements work in other languages would be too much for this post and could be a good topic for another one. However, there are a few rules that can be followed in preparing conditional statements for translation:
- If CAT tools ever advance in processing mail merge fields, I would want nothing else than one entire segment for each paragraph. Because context matters so much when evaluating these sentences. Maybe it’s not so bad that for these templates we are required to work directly in Word.
- Statements should not be too narrowly defined to fit only the English language. For example, we came across a conditional statement using something like under th{IF X=Y,”is“,”e“} plan. to say either this plan or the plan. Even though that’s very clever in English, it most likely will not work like that in other languages. Plus, it doesn’t read well for the translator. It’s better just to write out both options (the and this) in full in each condition. Even better would be to include plan into the conditional statement so that each statement is complete and can be translated completely in grammatical context (under {IF X=Y,”this plan“,”the plan“}.
- Avoid using the same variable text in two different contexts. Context can be difficult to predict for every language, but often issues happen when only part of a phrase is being conditioned while the other part is hard coded. This is something we read a lot in software localization where simple phrases like “Copy {X}” (where {X} is the only conditional value) may work well in many different contexts in English, but in other languages the context of X may change the term for copy (for instance, copying a setting versus copying text).
- The same can go for the use of adjectives with nouns or pronouns or adverbs with verbs. We’ve discussed before the use of adjectives in French and how the same adjective cannot be simply used over and over again for different nouns. Sometimes it is not possible to code for every possible context, and therefore time should always be allowed to do proper preflight on these.
Invest in processes that provides the best pay-off
Speaking of preflight, a lot of time is spent in preparation for translation on figuring out the variable data and its various outputs. A helpful method to combat out-of-context sentences is to provide samples that show what the output may look like. A lot of preflight time (done in project management) is spent on simply reading through the logic to see if there is any need for additional context and to identify any potential grammatical problems. Other things to look out for are intentional spaces either left in or out to render the final output without any spacing errors, etc.
Ultimately, the manual work put into the preparation and subsequent processes does pay off. It’s an investment that you make in order to get the right output that leads to desired behaviors. Plus, there is something satisfying in doing very detailed work that ultimately does save the client a lot of cost, and helps the end user by avoiding confusion and headaches in reading and understanding the material.
Are you a technical English writer? Does this give you insight into working with translations? Let us know. Are you a translator that has worked with these kind of files? What has worked for you? Does project management in other companies help to simplify the task and overall understandabilty for the translator and reader?
