Our Analysts' Insights

In recent years, there’s been a lot of buzz around “headless” systems – whether for content creation and management or for the translation workflows that feed the global customer experience. The concept being that rather than having a traditional front- and back-end (publishing and creation), these systems allow content to be magically managed, extracted, repurposed, and delivered through a myriad of end points, from mobile apps to corporate websites integrated with a partner’s own custom publication. Content creators work within the tools of their choice; automated processes make sure their work is translated to the appropriate languages; publishing and delivery systems select and share the right content, in the right place, and at the exact best time. It’s advertised as a global, multichannel content environment.

Sounds perfect? At the conceptual level, yes it does. It’s the reality of “reusable content” that people have been striving for since beginning to structure content with SGML and its cumbersome content models. Sounds too good to be true? It is, if you only think about the concept, and not what happens before chopping off a head. Way too good to be true if you don’t spend enough time architecting and planning the end-to-end infrastructure, connections, and monitoring points. It’s a bit like a city’s transit systems with automated vehicles and trains: the doors need to open only when the carriage is standing at the right spot in a station, otherwise someone will get hurt.

A headless system relies on the work behind the scenes: the content model, the workflows and processes, the alerts and triggers, the automation. None of this happens by itself – yes, AI and machine learning is increasing in use, for example to identify the most appropriate machine translation engines and/or linguists, but – so far – it’s not pervasive throughout the content lifecycle. (Other than by those SEO-geared web bots that publish badly-curated and translated content purely to expose you to pages of inane ads.) Even when AI is one day able to select, then perfectly-translate content, and publish or share it, it will still need planning – and human oversight.

If you’ve read the 2011 novel, "The Fear Index", by Robert Harris or seen the recent Sky TV series, based on the story, you’ve seen a dystopian view of a system that’s controlled by artificial intelligence. It becomes a Frankenstein’s monster, thinking – misguidedly – for itself, like a genius but without morals. Doing the “right” thing – but being completely wrong. We’re not suggesting that a headless content- or translation-management system is anywhere near this level of risk – yet – but you do need to take steps to make sure your headless systems are guided by an active and engaged human brain.

Headless components can be risky if not monitored to prevent them from making excessive or unanticipated requests for services or launching undesired actions. Many localization problems arise when localization teams fail to verify output from these systems after they completed the translations. As a result, they require careful set-up, planning, and monitoring – especially if multiple components are headless (“Language Technology Solutions: Enterprises”).

Where do you need to be involved?

• Design. First, someone must design the entire system from content creation through to all publication points; from overall concepts – such as the website, the app, a brochure, or a newsletter – right down to individual chunks and components – a heading, a paragraph, or the container for a banner image. How are those content units propagated – for example, to feed flows for all English- or Spanish-speaking locales – for audiences that expect information tailored to them? That process or hierarchy needs future-proof consideration. You must take care to plan controls and rules to answer questions such as what happens when something unexpected occurs. You must design processes for a continuous flow of content – do you use machine translation then replace it with human-edited once the linguists have had time to do their job? Or do you wait for transcreation prior to publishing – and does that hold back the source publication? Then there are delivery methods to consider: who or what selects which content to share, to where, and when? Only when the entire architecture has been designed, configured, automated, and tested can it operate without a head.
   
• Management. Second, understand that headless doesn’t mean unmanaged. Take a TMS: even when integrated seamlessly with a content management system, with automated processes for delivering translations back and forth, that TMS needs to be configured for the CMS content, with machine translation engines, translation memory, terminology, and human resources available as needed. It must be set up to notify someone – or something – about exceptions, such as a linguist delivering late or a file format error. It may need occasional tweaking – imagine a change in brand terminology or modifications to fast-evolving inclusive language (“Inclusive Language”). 
   
• Context. Third, help all involved to know the value of the context. An extreme environment – with a fully-automated TMS daisy-chained to one or more headless CMSes or code repositories – likely doesn’t present any visual context to the linguist without a lot of effort at the design stage. This context might be achieved through detailed metadata, automated screenshots, or stylesheets shared with the linguistic environment (but even then, it’s only one context, not the multitude of potential presentation methods). This means that it’s essential to train content creators on what to deliver as part of the context if it requires human input.

Yes, a headless global content flow can work – and work well. But it’s the result of an investment of time, expertise, design, and an awful lot of testing to make sure it all works as planned. Start small to validate your content model and how languages and locales fit within it. Remember that your source or HQ language – whether English or another tongue – is just another language, meaning that you want source content that is globally-generic, ready to be tweaked – if needed – for a variety of locales, rather than beginning with US-centric information that must always be modified, transcreated, or completely rewritten.

Your global content environment can, with careful work, be headless – but don’t lose your head and expect it all to happen by magic!