- Not our problem
- We’ll export the content and you can cut and paste it back in (a.k.a “Not Our Problem”)
- Have the translator login to the system and do the translation there (a.k.a “Not Our Problem”)
And for many years none of the attitudes were the “wrong” answer to speak of as translators were still largely working on purely people powered, manual processes. Anecdotally we’ve seen a lot of evidence that the content management and translation industries still operate in very different spaces. Some of the big guys on both sides have made attempts at connecting Content Management Systems with Translation Management Systems which is a good start. Recent announcements, such as LISA and Gilbane working together to offer a globalization track at the Gilbane conferences this year (CTT will be at the San Francisco show Apr 10-12) are also good signs that the two sides are entering into a dialogue that will benefit everyone.
That said though it’s still an almost daily occurrence where I have a conversation with a CMS vendor/integrator/customer or read a case study where the extent of “integration” involves throwing content over the wall at the translators or letting the translators come into the system to do their work right there.
Looking for the “Translate” Button
A Common Sense Advisory study recently suggested up to 91% of the content translated by a TSP is still down through a mostly manual process. I think a common mistake that occurs is many people unfamiliar with the translation industry make too big a leap when they start considering an integrated approach to translation management. We continually, as a I suspect many other translation technology vendors do, have to educate potential customers who immediately think that our software will perform the translation for them. The panacea for content creators and managers is that a company will come along and offer them a big red button with “Translate” written across it – all they have to do is push it and instantly their content comes back translated. Tools (toys?) like Babel Fish and Google’s Machine Translation system are dangled in front of them and to the unfamiliar they make it appear that the big red button is here (or quickly approaching).
The reality of course is that despite the advances by companies like Language Weaver, it is still a long ways off and the human factor of translation is still very, very much part of the process – and I believe it will always continue to be. The key thing to remember is at the end of the day every machine translation system out there still need to be taught – Taught with content translated by humans.
The real trick here is to back people a few steps form the big vision. They can, and should, have the “Translate” button today but their expectations around “time” need to be tempered. There’s no excuse today why the process from just after someone “creates” and the translator “translates” isn’t completely automated but the human translator, just like the author remains a critical component of the process.
The Content Lifecycle
The content lifecycle is typically depicted as the notion of one system controlling the entire process in one continuous loop. If a task can’t be performed within the confines of the application then content is typically unceremoniously spit out and content managers must pick up the mess and have the translation performed. At the translator’s end they get a deluge of assorted files form clients, in various formats and they must scramble to assemble the project and perform the translation.
My suggestion though is that this is only half of the picture, and not a scalable approach. Just as content authors should be free to work in the tools that allow them to be most effective, so should translation professionals – and neither side should have to perform the same, time-sucking tasks over and over just to get the content into and out of the translation process. For this to happen content needs to move between systems to suit the context of the tasks that need to be performed on it.
The reality is as content moves through it’s master lifecycle it actually moves through different systems which each have their own workflow “eddy”. Each system controls the content as it moves through its own internal workflow . This type of system is what I refer to as the Integrated Content Lifecycle (ICL).
Make Applications Open
The challenge today with the notion of an Integrated Content Lifecycle is many of today’s systems just can’t support it and competitive forces continue to keep applications closed, rather than open. Old school thinking was you build a killer product set, close it off and then made your money selling all its bits and pieces throughout an enterprise – another company wants to work with your client? They buy your software too! Easy!
Today though, that just won’t work – with the growing momentum of Service Oriented Architecture (SOA) or “Web Services” corporations are expecting more and more freedom and flexibility.
There’s also the matter of multiple organizations in the mix now. In a monolingual context it’s certainly possible that the content lifecycle will never extend past a single system, let alone past your company’s walls. With multiple languages though the likelihood of external vendors being involved is very high and you’re almost guaranteed to need to move that content from one system to another during the course of translation. As I mentioned above the tools used by a content manager, and those used by a translator can be very, very different.
I’m not saying a software company shouldn’t make their software interact with their own products – I’m suggesting the opposite in fact. By all means they should build their systems so they tightly integrate within the family, just not at the exclusion of all others.
Here’s the kicker – I mentioned before about competitive forces keeping systems closed, the reality is taking this philosophy should actually make it EASIER for an organization to make a better product, more efficiently with a completive edge that will translate into more sales. How? When you’re a closed system your product has to do everything for that given process – even if it is only really good at one component of the process. With an open system you a free to concentrate and improve on the specific features or functions your software does best and then find partners and other software that helps complete the picture for your clients.
If you have a closed system you have two options when a client asks you about a key feature that you don’t support/do very well. Try and roll it into the product (another feature to support/build) and hope the opportunity still exists when you’re ready or say “we don’t support that” and risk losing the sale.
For an open system the answer becomes much easier “We don’t natively support that but we’ve partnered with company X who does and we integrate directly to them”.
And to be clear, these aren’t just giant LSPs or massive multi-nati
onal corporations that I’m talking about, these are small companies whose entire margin for the year could be sucked up quite handily with a typical custom integration project. On all fronts there is a clear and pressing need for systems to openly communicate with each other in an easy, predictable fashion.
Increased Awareness & Conversation
I think the biggest challenge to date though is still one of awareness. It’s almost like a blind date by ambush – only by the time the CMS guys realized they were on a date they’re married, have kids and a most importantly a wife who’s tired of being just an afterthought.
I’ve seen many CMS companies patting themselves on the back for their “multilingual” support but once you dig deeper the level of support is that they display multiple languages (I mentally give them a UTF-8 “gold star” each time). Those who have some support for managing synchronous versions of multiple languages often respond to questions about workflow with one of the three answers listed above – it’s not because they don’t care, I think a big part of it is they just don’t know. Just about every CMS vendor who we’ve talked to, once we explain how it can work, is on board with the notion of bringing more automation to the process (it saves them a lot of headaches too).
As I mentioned before though, both sides are waking up to each other right now, well CMS is waking up, I suspect the translation vendors are laying awake thinking “It’s about time”. With the Lisa/Gilbane arrangement and the GALA pavillion at AIIM the awareness between the two camps is only going to grow and I think we’ll see a lot of exciting changes.
That said, the localization/translation industry could admittedly be a little more vocal – it’s taken us a good three years now to start to get some understanding of the industry as a whole, but it is still a weekly occurrence where we discover someone or something that was completely under off our radar. Slowly but surely blogs are starting to appear but I think there’s a lot more discussion that needs to happen by translation & localization professionals out to the market at large. The language industry as a whole is a very complex place and it really is encumbent on the people who know and understand it to help the people who turn to it understand the best practices.
(As a sidenote: if you write a localization/language/translation blog add it to the comments below and I’ll compile a list for a future blog post)
A sense I get a lot is that Translators, as frustrating as it is for them, will take just about anything from clients – a grin & bear it type scenario. This is unfortunately just a result of the fact that for many years that grin & bear it was really their only option, but with technology advances and changes on both sides it’s getting less and less necessary.
I was amazed when I was talking to one LSP and they mentioned there were over 20 different client systems that their translators would log into in order to work on jobs. 20! Integrated Content Lifecycles would allow that organization to use one central workflow tool, while allowing their clients to connect their workflow and management tools to them. Imagine the savings for both sides.
Over all I think the general theme is “Be open and interact on all levels”. From the back office systems all talking to each other in one cohesive infrastructure to the people on the front lines working with each other to understand the full spectrum of what’s involved. The language and content management markets are at a major intersection where both need to get in sync with each other so we all go down the same, prosperous path together.