Multilingual challenge: Node vs. Field

Katrin Fartaček's picture
Katrin Fartaček

So there was a DrupalCon in Munich and we were there! Many people, much information and a lot of excitement for Drupal 8!

One of the best sessions I attended was by Suzanne Kennedy (aka pixelite) about "Multilingual Content in Drupal 7 & 8" You'll find the whole presentation as video and pdf there.

I always had trouble which translation type to choose, because I didn't get the difference. And so many words and modules: field translation, entity translation, i18something,.. do I need all of them, just some, why is my content translatable but the tags are not? ... and on and on...

well pixelite cleared it up for me!

But since I never watch whole presentations again and just need a small reference so next time I build a site I can just check: what do I need and what satisfies my needs. And yes there is documentation about it ( and if you have good sources don't be shy and leave comments!)

But she was the only one who made me get the basic idea behind the drupal translation concept. So I thought I share her wisdom (well at least the scribbles I took from her wisdom) with the world:

Reasons and stuff to think about beforehand:

why even make a multilingual site if it's such a pain?

  • to reach a wider audience
  • to serve new markets
  • to improve usability
  • to improve search engine optimization
  • to ge along goverment regulation
  • to satisfy company policy

Translating content is costy!  (in time and money)
You need someone to translate content and/or to review machine translated content. But you don't only need someone for the content: the user interface also wants to be translated.

There are two important modules that handle translation:

Internationalization
aka the i18n module
this enables localization of content and other elements

Localization
aka l10n module

you should make a detailed plan of what exactly your future site will contain on multilingual features. pixelite points out three major scenarios for site setups:

 

  1. the foreign language site (you would set a different site language: locale module)
  2. the multilingual site (the user interface should be available in more than one language: locale, i18n)
  3. the multilingual site with translation (the ability to translate content adds extra layer: locale, i18n, entity translation or content translation)

You also have to decide if you show only translated content or also untranslated ones.

In D7 there are different types of translatable fragments, which interfaces are scattered all over the place (seems in D8 this will be better)

types of texts you have:

  • user interface (code)
  • user interface (user defined)
  • i18n strings
  • variables
  • content

(if you enable entity translation, more things fall into that category, like taxonomy terms, users, contributed modules entities,...)

So now the big question:

In what way should you organize the translation of this various content?
There are two possibities:

NODE LEVEL

Here you would use one original node and create for every translation a seperate node in that language, which has a relationship to the orignal node (a translation id)
so you have: node 1 (en), node 2 (fr), node 3 (de), ...

Kind of a drawback is: this creates a lot of nodes, where you need to synchronize data inbetween. And since everything is language specific, you have to upload for instance images several times. Also meaning that it doesn't work for language neutral things (like people, products,...) only for nodes.
But there are positives too: you have independent nodes, so asymetric menus possible. Which is good if you have just some content in another language. It also works for node based functionality (like search!).

FIELD LEVEL

Here you have just one node. You will translate fields instead of nodes. The entity translation module provides the UI, actually fields are already translatabe in core.
So you can leave all those language independent properities (like voting, flags, signups, draggable views data, moderation, scheduler, entitty references, panels nodes' layout, social media integration, content access,...)

The big positives are there for: better dealing with neutral content, no need to sync properities, just one node to handle.
Nevertheless there are drawbacks too: It doesn't work with core search or revisions (only in original language of the node)
Translators have to get used to a different ui. It is not compatible with node options or with the multilingual select features from i18n.
And properities can't be translated yet (but d8 will do that)
 

Important note at the end:

decide on one translation method in the beginning and stick with it! Changing it will awake evil drupal demons and things will start behaving more strangely than usual...

Comments

Field level translations do not seem to support revisions and separate publishing control either. With field level translations your published state is controlled at the node level so if you wanted to unpublish a German translation while you worked on it and kept the English version live both would need to be unpublished.

Video presentation - Multilingual Content in Drupal 7 & 8 is not working.
Thx for effort to explains drupal multilingual problem.

Add new comment