So there was a DrupalCon in Munich and we were there! Many people, much information and a lot of excitement for Drupal 8!
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:
aka the i18n module
this enables localization of content and other elements
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:
- the foreign language site (you would set a different site language: locale module)
- the multilingual site (the user interface should be available in more than one language: locale, i18n)
- 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
(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:
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!).
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...