Val Swisher was the next to last individual to speak at the Adobe Day at Lavacon 2013 event. For those who are regular readers of this blog, you know that my love for all things Val Swisher has no bounds. I’ve always been able to take her easy-to-digest information, and absorb it quickly into my brain, as well as relay her knowledge to others. When I looked at Portland Gardens to compare her to, I chose Ladd’s Addition Rose Garden. While it’s not as well-known (unlike Val, who is very well-known), this particular park, according to The Rose Garden Store, was one of four rose gardens especially built from the Ladd estate, in which the design included these gardens coming together to form the points of a compass. I often think of Val as my compass, as she has never steered me wrong with her information or with the wisdom and fun that she’s shared with me one-on-one.
Val’s Adobe Day presentation centered on talking about source English terminology in a multi-channelled, global world, and how terminology affects structured authoring, translation and global mobile content. She started the talk by reminding us that historically, we’ve always created content, whether it’s been on cave walls, through stenography, through typewriters or eventually on word processors. In every instance, consistent terminology has been essential for structured authoring and content. Managing terminology is also essential for translation and for reuse. She stated that prior attitudes used to be that the more complicated the writing was, the more “fancy” the product was. Today, that’s definitely not true. She used the example that I’ve heard her use before, but it’s so simple itself that it’s a classic. Her example involves writing for a pet website. If multiple words meaning dog are used, there can be problem with reuse, because you can’t reuse content if you use different words.
Val pointed out that it would be an even worse situation if technological or medical terminology was used instead.
Val continued by saying that when it comes to XML, reuse , and terminology, you cannot realize the gains of structured authoring if you’re not efficient with your words. Terminology is critically important to gain more opportunities.
Translation comes down to three elements– we’re trying to get better, cheaper, and faster translation output. We MUST use technology to push terminology and style/usage rules to content developers. In order to make it cheaper, we need fewer words, reused words, and reused sentences. It’s impossible for writers to know or even know to look up all term and usage rules. We MUST automate with technology. For example, “Hitting the button” is not translatable, but “Select OK” is fine! She said, “Say the same thing the same way every time you say it.”
For better translation, translation quality needs to improve and meanings need to match in order for better machine translation to be a possibility. Bad translation comes from the source itself. If the source information is problematic, then the translation will be problematic. The best way to save money and time is to say the same thing, every time, using the same words, and use shorter sentences. For machine translation, don’t go over 24 words in a sentence.
Faster translation is seen as content that takes less time to translate, needs fewer in-country reviews, and gets to market more quickly. The key to delivering global mobile content is responsive design, global mobile apps, text selection is key, and terminology is the most important element. Val showed this example of how translation in responsive design isn’t working, where the Bosch websites are not exactly in synchronization:
The simpler the design is for the website–especially in mobile, the less you have to tweak it. This is especially true where consistent terminology is important, because consistency is needed for structured authoring. Creating truly faster, cheaper, and better translation enables a true global responsive design. This is not a simple task, as there is no such thing as simple, even when writing about complex concepts. Even if you think you’re not translating, your customers are, so the content needs to be very clear. The scary part of this is that some companies use Google Translate as their translation strategy, which is risky at best. To use something like Google Translate as the translation software, the content had better be tight, clear, and consistent.
One of the things I enjoy with Val Swisher’s presentations is that it all comes down to common sense, and she breaks it down into easy manageable parts for those of us–like me–who might not have thought about the context of language for structured authoring, and the consequences for not strategizing content to include translation considerations.
I highly recommend checking out Val’s blog for other great insights.
(As always, Val–if you’d like to add or correct anything here, please do in the comments below!)