Translatable content: the four basic models

Online businesses are rapidly going global, which means that offering content in the native language of your customers becomes more and more important. Now imagine that you want to automate your translations using machine translation from Google Translate, SDL or Lionbridge. Or imagine that you want to publish your content through a platform like Liferay, Sitecore or Adobe Experience Manager. What would be your key challenge for implementing the translation workflow or publishing flow of your translated content? To answer this question, we first need to take a look at how translations are handled in content repositories.

Four models for translation
Over time developers have sought clever solutions to implement translation into their products. There are four models that are most frequently used:

Model 1: Detached
This is the most basic model. In fact, there is no real model at all, it is just based on a naming convention. For example, take a document on your computer. It's written in English so you store it in a folder called "English". Then you create a translation into German and store that document in a folder called "German". This translation model is "detached" because there is no formal mechanism in place to deal with the translations other than the naming convention. The detached model is used informally in ECM systems in many organisations, but can also be found in many WCM products.

Model 2: Linked
Much like the detached model, there is still no formal mechanism for dealing with translations. However, the system does store some information on documents in the form of metadata. E.g. it stores the language of the document, and it has the capability of having a "translationOf" relationship with other documents. The linked model is popular in ECM and WCM systems that originally had no support for translations at all, but found clever ways to leverage their metadata model to better support translations.

Model 3: Embedded
The embedded model is the first to introduce a formal approach to translation on an API level. The API can perform CRUD (Create, Read, Update, Delete) operations on translations of a document. In this model, each translation is still considered its own stand-alone document. The formatting of the content and the availability of metadata may differ between translations. This model is the most commonly found model for systems that have support for translations.

Model 4: Transparent
The fourth model is also the most advanced one. Next
to having full API support, translation is actually handled on a per field / per content segment basis. Translation is essentially transparent to the user; all content and metadata is inter-exchangeable between translations and follows the same conventions and quality rules. You will find this model being used often in more advanced systems such as for example digital publishing platforms and product information management and master data management products.

Building your integration solution
The everyday problems your developers will deal with are on the level of how to handle: translated metadata such as title and keywords; location-specific images; and formatting content consistently across translations.

The key to a successful implementation lies in identifying the underlying translation model early on in your project and understanding how to map this to your translation workflow or publishing workflow.

Also, don’t forget to have a look at our Xillio API, which handles all mentioned translation models completely transparently for the developer.

-----------------------------------------------------------------------------------