Quality translation dictates a collaborative effort

Some in our industry argue that an in-country proof is not needed after the translation of a product is completed. I can’t disagree more.

Control Theory teaches us that a dynamic system remains unstable until it has a negative feedback loop built into it.

Look at the graph on the left and think of r as the source text. The target, or translated text, is y. G is the translator and K is the in-country proofreader.

K will have to proofread the translations of G and offer constructive (negative) feedback to the translator to help meet the required quality.

The translation management system is H. It is a dynamic system. For it to be stable, it will require to properly handle input from G and K− the translator and in-country proofreader.

Also, to ensure a stable system, collaboration among the different influencers in the system will be needed. The more efficient and optimal the collaboration efforts are, the more stable the system will be.

Translation Management Systems (or TMS) today leverage Web 2.0-like collaborative tools. Translators submit their queries to the in-country proofreaders using a wiki tool integrated into their translation environment and get timely answers back. Terminology is shared with the crowd and is put to its scrutiny, improving its quality and usability. And already translated segments are efficiently leveraged from previously built translation databases for the same company or industry.

What is the moral of this blog? Despite of what others may tell you, don’t let your translators translate in vacuum. Translation is not a task that you can throw over the wall to others in a process that excludes your input and guidance. If you do that, the translation quality will sooner or later diverge from your requirements and your end-users will someday give up on using your localized product.

Therefore, quality translation requires a collaborative translation management system. One that permits information sharing, that improves terminology understanding, that tracks schedules and tasks, that facilitates the feedback process, that ensures data sharing and conforming and that truly allows a two-way dialog to improve product quality and usability.

Next time you are told to forego your in-country proof, ask your localization or translation vendor to consider using a robust translation management system, or better yet, hire someone that does! −QED.

Would you build a tower on a crooked foundation?

While in process of validating new international markets, and in an effort to reduce new market entry costs, many software publishers delegate the localization of their product to a distributor or a value added reseller (VAR).

The VAR, to minimize overhead, attempts to sell the software in English, but soon finds out that the market potential is very limited when the product does not speak the client’s language. Hastily, they use machine translation or assign the localization task to a field engineer to complete over a weekend or two.

With the Graphical User Interface (GUI) “localized”, the VAR can now tick the language support checkbox during product evaluations helping sell the product in this newly created market.

Encouraged by the rising sales, corporate decides to invest further into that newly developed market and takes over the localization effort in that language. With the GUI already “localized”, they decide to augment the offering by localizing the help and manuals.

Ignorant about the horrific quality the localized GUI is in, orders come from upper management to the localization group to adopt the localized GUI and proceed with the localization of the help and manuals. When the localization group objects to the quality of the localized GUI, they are sneered at stating that the GUI is fine and that the product is already selling as is. “Just do what you’re told!”

The localization team takes the marching orders in stride and proceeds to localize the help and manuals making it consistent to the appalling terminology used in the GUI, trying hard to work it out. But the further they proceed into their work, the more obvious it becomes that none of it will make any sense once complete. The only recourse is to completely redo the GUI and then thoroughly edit the translations that have taken place.

Aghast at the costs and delays involved in correcting, not just the GUI, but also the voluminous help and manuals, management points the finger and its localization team.

You see, you cannot build a product on inaccurate GUI localization. GUI elements, such as menu items, tool tips, dialog boxes and error messages are referenced throughout the entire help and manuals. They have to be accurate and consistent for the product to be useful to its users and for the help to have a chance to help. The GUI is the foundation of the product. Building a localized product on a crooked foundation will lead to the collapse of the entire product. If it does not collapse, it will remain forever as vacant as the leaning Pizza Tower!

It pays to have your GUI carefully localized. GUI typically is not very verbose which makes it harder, but not as costly as help and manuals to localize. Take care of your product’s foundation and the localized help and manuals, the training and tutorials, the website and the sales collateral, will all fall nicely in place!