An Oracle blog about translation

Context for All

Interesting post over on the Content Rules blog, discussing the issue of context (or lack of, really) for translators, and how it relates to granularity of content. It's great to see this issue raised and I think we need to be a lot more hardcore about examining the claims about how intractable the problem of lack of context for translation can be.

For me, the problem with this context debate is that it is decontextualized (ho, ho) from the total content lifecycle and the tools and process side of things. For one thing, has anyone considered what context an application developer or technical writer has when reusing content (whether burst DocBook objects in a CMS or DITA conrefs)? Is it any worse/better than what translation teams have? Surely, if content developers have context from their CMS (or development environment) then isn't the issue why translators aren't accessing the CMS/environment and working in there too? Why ever remove content from a database just so to translate it?
What is very clear to me is that context can be easily and automatically derived from the development environment and included within a translatable file format, if you so design it. Here's a simple Oracle-related example:


Information quality helps a lot here too. A term should only have one meaning in that context. So, derived context, information quality, and repository-based operations can solve the problem. Sure, a badly written little piece of text copied and pasted into Notepad and sent around the world via e-mail is going to lead to trouble. Duh.

What translation teams should not be pushing for however, is dumbed-down text devoid of any real style or necessary references just to make translation easier. Contextual information is a critical UX. Bland, generic content is not - that stuff damages the UX in all languages. Nor should content developers have to "write in" context in the form of translation notes for translation teams. That is a waste of development time and resources. Derive the context automatically, instead.

Regardless of how this context is provided, the most frustrating part of this context debate is the lack of insight displayed by advocates about the application lifecycle. Context has been positioned by internationalization and translation teams as something exclusively required on translatability grounds. It's not.
In fact, context is a critical part of any UX-effective customization or extensibility efforts.

Less than a quarter of enterprise application deployments stay 'vanilla'. The rest are customized: modified for customer needs, and with extra bits of functionality added on that need to look the same as the rest. Without context for developers and functional users, such customization/extensibility efforts can be very tough indeed in UX terms. In fact, 'translation context' columns in databases are usually repurposed description columns intended for development, implementor and customization team notes.
That internationalization and translation teams never leveraged a wider argument in support of improved context doesn't surprise me.

I believe the context for all requirement is one that can be met. But it will be by UX people, and not translation teams.

Be the first to comment

Comments ( 0 )
Please enter your name.Please provide a valid email address.Please enter a comment.CAPTCHA challenge response provided was incorrect. Please try again.Captcha

Integrated Cloud Applications & Platform Services