Language lessons: What are you translating?

Content (node-level) translation or entity (field-level) translation?

It seems an obvious question to ask, but what are you translating?

The tools exist to translate just about anything in Drupal 7*, but in many different ways, so you need to know exactly what you're translating. Language is 'a first-class citizen', in the sense that any piece of text is inherently written by someone on some language, which Drupal 7 is built to recognise. Sometimes you want to translate each & every individual piece of text (e.g. at the sentence or paragraph level). Other times you want to translate a whole page or section that is made up of multiple pieces of text.

Your content is represented in Drupal as fields and entities (nodes, taxonomy terms, etc). The purpose of your content will dictate how it should be translated. For example, on an e-commerce website that has no difference in the product on offer when shown in different languages, every single sentence may be translated, but the page remains the same. In this case, the translation is at the deepest level of text - i.e. it is field-level translation. However, if the product offering is itself different when shown in different languages then the whole page could be completely different - perhaps with totally different pictures, keyword tags and links. Translation of this kind would be at a 'higher' level as the page is defined by the language - so it would be node-level translation (or page-level).

Perhaps the easiest way to understand this is to look at some examples, asking the question: How should a new translation be handled?

• An encyclopaedia article may be best translated by creating a whole new page that is just linked to the original article. This leaves flexibility for the content of the new translation to be quite different as it is a separate article. (Like on Wikipedia - translations may have different sections, pictures & references - they can be totally different in each language.) This is node-level translation, as a new article itself is created as a node.

  Each translation exists as a separate page.
  

• However, when translating a product page in a brochure into a new language, each piece of text on the page may be translated so that all of the actual information remains in place in the same way (just expressed/displayed in a different language). This is field-level translation, as the node remains but the data in each field is re-created. (Of course, some of the text may not need translating, such as numerical information, or it could just be omitted from a translation.)

  Each field is translated within a single page.
  

Hopefully the diagrams above help explain node-level translation and field-level translation. Notice that the content of each translation in the node-level model is free to be different, but this means the translations of individual fields are not tied to each other. In the field-level translation, the fields in each translation have to be the same, but this means each is linked as a translation. Linking the translations is useful when rendering parts of a translation separately - for example, in views where individual fields are listed without the whole page, or listing node translations side-by-side. The former can only be done with field-level translation, but then the latter is harder to do.

Field-level translation is achieved by using the Entity Translation module, while node-level translation can be achieved with Drupal core's Content translation module. Yes, these are confusingly named!

Drupal 8 core will use the field-level translation concept, as it is still possible to achieve a node-level translation model with it (e.g. by using a node/entity reference field to link the different translation nodes together), and for good reason. Since all text is inherently written in some language, I believe it makes sense for translations to be at the deepest level (i.e. field-level), rather than grouping different pieces of text (i.e. different fields) into a single defined translation.

If you're not sure, opt for the field-level model (with the Entity Translation module), and work out if your use case can be handled by it. You can use both models on a single site, but it may only confuse your editors, translators and site maintainers. Avoid trying to build too much, it will only result in confusion!

So, back to where we started: What are you translating? Let us know how you have matched the field-level or node-level translation models to your workflow and the challenges you have faced.

* (In Drupal 6, fields are provided by the CCK module, and there are only nodes instead of the more general entity concept. Only the node-level translation model is available in Drupal 6 - i.e. a node is translated as a separate sibling node. Any version of Drupal before Drupal 8 will require additional modules contributed by the community in order to be translatable.)