Node translation vs. Entity (field) translation

Question

I would like to know what you guys recommend for a multilanguage site. For example, consider the following case: A page and its content should be available in 3 languages (e.g. German, English, and Spanish); the site uses one profile type, several content types and views, taxonomy, taxonomy-references, node references, user and field references, field collections, menues and so on. All of this informations should be translatable.

As far as I know, there are two ways to obtain this: with Entity Translation and the "node-based" method, or the usual one with the Internationalization modules and l10n.

What way should I choose? In which case and why should I consider a method instead of the other?

Answer 1

Randy Fay recently created a post discussing the possibilities achieved with of Entity Translations, where Gabor Hojtsy commented on some of the considerations to weigh:

Some good things offered by [good old] node translation include support for separate node commenting (eg. your German and English comments will not be intermixed); support for per language revisions; publication workflows (eg. the German node can be in a pre-publication revision workflow while the English is already published, coordinated actions can publish multiple language versions when all reach a certain step in the workflow, etc); different permission handling (eg. certain people can only edit German translations not English originals), thanks to Drupal's excessive node access system, etc. Think about menus. Most sites do not plan to have 1-1 menu structures for all translated versions.

The major caveat as I see it for Content/Entity/field-level Translation right now boils down to that age old Drupalism special case: the node title... Its not really a field, so its not translatable without another module, and potentially some patch work. As of right now, I think field translation is still very much "experimental" ground, but more power to you for pushing forward into new territory.

Answer 2

Suzanne Kennedy and Florian Loretan's presentation at DrupalCon Denver addressed this question. It seems like entity translation is the way of the future and is at least partly slated for integration into core.

Their recommendation was to use entity translation unless you need support for revisioning.

Answer 3

I used Node translation but now after I tried Entity Translation, it's definitely my favorite one!

I think the main problem is the import function with Entity Translation, because there is a long discussion in the Drupal community. Otherwise I read about a new module, but I haven't tried it yet. But I will give you my feedback afterwards!

If you combine Entity Translation with the Title module, you can translate everything. I also prefer the module "Localization update".

So you have to install and enable these contributed modules:

• Entity Translation.
• Title.
• Localization update.

And you have to enable these core modules:

• Locale.
• Content Translation.

Good Luck!

Answer 4

I know I'm raising the dead here but:

From what I can tell, the 6-style node translation method (each translation is a new node) is still the only useful way to translate content, having the benefits of being what everyone is used to and being functionally complete. (Node titles are not fields in 7, and therefore cannot be field-translated, among other silly shortcomings.)

You're always going to use i18n/locale, the only choice (which isn't really a choice) is node level or field-level translation, of which only node translation is likely to be useful.

Edit: Since this was written, Entity Translation + Title module have made field-level translation very effective. If you can use them, you should.

Answer 5

Entity translation makes much more sense in most cases than node translation; but sadly it isn't really a viable option for D7 as many modules still do not support it. People that do presentations and show how great it is simply are only doing very simple work. For example, something as common/popular as field collections is still not supported by ET.

When we start a new multilingual site we always start with ET since it is a great idea. We stick with it until we find too many issues with things not being compatible.. and then eventually we switch back to the old D6 method.