The headline facts
Among web editors, developers, information managers and system architects, there was much talk in 2018 about the continuing rise of headless CMS. In general terms this refers to the distinction in a content management system between the underlying data and back-end admin interface on the one side, and the front-end output on the other.
So if an enterprise is using a CMS like Sitecore, Drupal or Umbraco to run a website, the traditional model is that the CMS application provides the web editors and technical authors with a user interface through which they accomplish their tasks: adding, editing and deleting pages; viewing metadata such as last-modified dates; reviewing, approving, versioning and publishing content; and assigning tasks to other users via workflows.
All these activities interact with the underlying content repository, comprising the back-end of the CMS. When a user sets an item of content to be live/published, the CMS pushes that content to the front-end, combining the content with the presentation layer – in other words, it generates the page on the website itself, where it will be visible to the general public on a mobile or desktop browser.
The decapitation bit
In a headless CMS, that website output – the “head” – doesn’t exist. Instead, the CMS application provides the underlying database and back-end, together with a set of APIs allowing interaction with that database and functionality.
The organisation deploying the CMS would then build their own front-end (head). Or indeed multiple heads. That’s because a key driver for the headless approach is to be able to more easily take an omnichannel approach. Instead of being locked into one development environment aimed only at web output, a headless CMS could allow one team to design a website using .NET, a second team to build a mobile app for Android, and a third team to code some interaction with Siri using watchOS. Via the APIs, all three tools can interact with the content in the CMS, presenting it in entirely different ways.
Related to this is the benefit of complete customisation, which can be much easier to achieve when building a front-end from scratch. Trying to customise a website can be bewildering when you try to force the square peg of your requirements into the round hole of the templates and code snippets which a traditional CMS might require. If you’ve ever tried to manually tweak a WordPress .php template, only to find that it has destroyed the layout of every page on your website, you’ll know what I mean.
Integration into existing business systems is another reason why an enterprise might choose a headless CMS. They might already have an in-house application which needs to pull together content from multiple sources – for example, the CMS repository, a separate PIM database and a separate finance system. The APIs allow their developers to extend an existing application, even though that application might present content in a completely different way.
Heading into the translation world
Enterprise clients with multilingual requirements (whether for documents, web content, software localisation, multimedia files or anything else) typically work with some form of TMS – a translation management system.
Just like with CMS technology, different TMS applications offer slightly different functionality. But a typical TMS would allow users to securely submit content for translation; view order status; review and approve translations before they go live; securely download translated content; and report on word counts and spend.
All of this would interact not just with the services provided by project managers, translators, proofreaders and other linguistic personnel, but with underlying translation databases in the form of translation memories, glossaries and other structured bilingual or multilingual content.
And just like with CMS technology, plenty of clients – in fact, most of ours – want a pre-defined front-end to work with. In the case of our proprietary TMS, i plus®, the front-end which clients see for tracking status, reviewing translations and downloading translated files is a secure web application.
Ahead of the curve
But increasing numbers of clients with complex business requirements and multifaceted systems want the advantages which APIs bring.
Some want to take advantage of publishing translated content directly to omnichannel output – without having to pull translations back into an intermediary system first. Some want to customise the way they send files for translation, providing users with a submission form built by their own developers in the programming language of their choosing. And many want to integrate translation services into a third-party or in-house application, or build their own lookup tool so that users can search the contents of translation memories or terminology databases from their own network.
At translate plus we have clients doing all these things, to the extent that many clients now only interact with our i plus platform via its APIs. In that respect, we offer a headless TMS for those who don’t need a front-end – and it occurs to me that we’ve been doing so for years. But perhaps it just wasn’t called that before!
Our clients can send and receive content for translation, obtain and approve quotes, retrieve status and reporting information, and access linguistic databases using any development environment they want – all without a human ever needing to log on to the i plus front-end. For example, one of our clients offers a range of business services, some handled in-house, others (like translation) handled by external partners. They have effectively recreated most of the i plus front-end for their customers within their own web platform, using a different programming language and interacting with their in-house finance and authentication systems. Our headless TMS clients never “see” i plus.
Sticking my neck out
So, to wrap up, I admit that this is my shameless attempt to get an article to rank #1 on Google for the phrase “headless TMS”. After all, about 90% of the spam e-mails I receive assure me that “getting to #1 on Google” is the Holy Grail of business.
As of January 2019, the only other hit for the exact phrase is an error-laden automated transcript of a talk in which it was output as “TMS” instead of “CMS”. Did I mention that translate plus also offer proper-quality transcription services?