26

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?

8

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.

  • Thank you. Very interessting points and pro's for node translaion. – Lance Mar 19 '12 at 7:52
5

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.

  • 2
    Indeed, Entity Translation is now part of Drupal 8 Core. According to its project page. – tanius Jan 24 '15 at 19:01
5

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:

And you have to enable these core modules:

  • Locale.
  • Content Translation.

Good Luck!

  • Great summary about this topic, +1 ! – Pierre.Vriens May 24 '15 at 8:39
2

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.

1

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.

  • Could you provide some more details on the difficulties you've experienced? We're in the same situation you described (creating a new site, need to decide model we're going to use for translation), and I'm wondering if our site is simple enough we won't encounter the problems you have. Knowing more details of your experiences would be extremely helpful. – Josh Dec 17 '14 at 22:18
  • There are over 6000 modules for D7; hard to say which ones will work and which won't. I know field collections does not translate properly with ET. I am sure there are others. Best bet is to try out each bundle as you create it and see if it can be translated using ET. You can mix ET and NT in the same site; but not within the same bundle. That makes ET more dangerous as if you end up adding a field type later that you hadn't previously verified and it isn't supported; or you add some functionality not supported; you might be in trouble. – liquidcms Dec 19 '14 at 4:35

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.