Presentation at DrupalCamp Kyiv (Sept.14-15, 2012) - an updated version of the presentation made for DrupalCafé Kyiv in April 2012.
http://camp12.drupal.ua
2. Outline
• What do we want from a multilingual site?
• Why do we need Entity Translation?
• Is it just “proof of concept” – or already usable?
• How does it work?
• Problems and solutions, pros and cons
• Conclusions
2
3. Extreme cases of
multilingual sites
Fully symmetric case: Very asymmetric case:
A spherical multilingual Separate sites with
horse in vacuum independent content quite
loosely connected to each
other
3
4. Can you really make your site
perfectly multilingual?
• Can you always get translations of all items
whenever you need it?
(Fast, good, and cheap – pick any two)
• Are all items relevant for all languages?
• What about user-generated content (if any) –
comments, forums, etc.?
4
5. What do we want?
• In real life, we usually have something in between
these two extremes
(some content is different,
some items are not translated,
user-generated content is not translated, etc.)
• We may not need it in this specific case… but we
want tools to build an ideal multilingual site when
we need it
5
6. If Drupal nodes were designed as multilingual
from the very beginning…
node/1
Title (lang1) Title (lang2)
(multilingual)
Body (lang1) Body (lang2)
Some field (lang1) Some field (lang2)
Another field (language-neutral)
Some file attached (lang1) Some file attached (lang2)
Another file attached (language-neutral)
comments
6
7. However, Drupal nodes are unilingual.
i18n is an external feature.
node/1 Title node/2 Title
(unilingual) (unilingual)
lang1 Body lang2 Body
Some field Some field
Another field Another field
Some file attached Some file attached
Another file attached Another file attached
comments
Drupal i18n system: I hereby declare node/1 comments
and node/2 to be translations of each other 7
8. Multilanguage: inside or outside?
Two possible approaches to i18n:
• Multilingual features inside an object
• Unilingual object, multilanguage features are
applied from outside as a system of
connections to other objects
“Object” can be a node, a block, a taxonomy term,
a menu, a menu item, and so on.
8
9. No field-level language attributes:
Why it can be a problem? Example 1
node/1 Title Title node/2
lang1 lang2
translation
Body Body
synchronization
Money field
Money field
Synchronizing money between nodes
is REALLY critical 9
10. No field-level language attributes:
Why it can be a problem? Example 2
node/3 (en) translation node/4 (uk)
event info event info
nodereference nodereference
translation node/2 (uk)
node/1 (en)
location info location info
You need to synchronize nodereferences
(i18nsync)
10
11. Problem with multilingual views based on
nodereference
en/events/by-location/ uk/events/by-location/
Events grouped by locations: Розподіл подій за місцем
проведення:
Kiev (6)
Київ (6)
Chişinău (4) Кишинів (4)
en uk
en/events/by-location/36 uk/events/by-location/37
List of events in Chişinău Перелік подій у Кишиневі
en uk
“Chişinău” (node/36) and “Кишинів” (node/37) are different nodes,
so when you switch language EN -> UK while viewing the “List of
events in Chişinău” you will see an empty list instead of “Перелік
подій у Кишиневі”.
11
12. Inside vs outside
• However, the “outside” approach can have
some advantages, too
– It can be simpler to do or maintain
– It can utilize such node-level things as access
permissions for nodes having certain attributes
(e.g. when you have different people working with
nodes in different languages), and so on
• It’s highly desirable to have both possibilities,
and choose between them depending on the
specific situation.
12
13. Things to translate
• Content • Interface
– Nodes (UI language may
– Blocks be independent of
content language)
– Views
– Menus
– Taxonomy
– Variables (site name,
slogan, and so on)
– etc.
(Internationalization) (Localization)
13
14. What is ”i18n” and ”L10n”?
internationalization i18n
18 letters omitted
10 letters omitted
Localization L10n
These abbreviations are used in the names of
Drupal modules, such as “i18n” or “L10n_client”
14
15. Drupal 5:
NO multilanguage support at all in the core
• No database fields to define node
language and connect it with its
translations
• Multilingual sites can be built using
contributed modules:
• i18n or Localizer
(Localizer was discontinued, not
survived till D6)
15
16. Multilanguage support in D6 core
Three fields added to “node” table
node.language
node.tnid
(= original node’s nid)
node.translate
(translation status)
And two new modules
in the core:
• Locale
• Content translation
16
17. Drupal 6
• Theoretically, it’s possible to build a multilingual
site using only the core modules…
• But in practice, you do need a contributed module
(i18n) to handle lots of things associated with
translation, synchronization, and visibility of
blocks, menus, views, variables, taxonomy, etc.
etc. etc.
17
18. Drupal 7
• Lots of new features and
improvements related to
multilanguage support
(see my last year’s
DrupalCamp Kyiv presentation
www.slideshare.net/G_N/d7-
i18n-2011)
• We still need the i18n module!
18
19. And now something really new…
D7 core has built-in support for field
languages!!!
(via its new Field API)
However, D7 has NO built-in interface for
translatable fields
We need to use some contributed
modules
19
20. Entity_translation module
• Can be used to translate fields
• As of September 12, 2012:
– 7.x-1.0-alpha2, 7.x-1.x-dev
– 4221 sites currently report using this module
(there was <100 in April 2011)
• Needs Title module to translate node titles
20
21. Under the hood
• Drupal 7 already has ‘language’ property for fields
• Entity translation module provides an interface to
use it
• Here, two values of the body field in two
languages (‘en’ and ‘uk’) are attached to
the same node (entity_id=1) 21
22. After installing Entity translation module, we see..
/admin/config
•fff A new item in
Regional and Language settings:
Entity translation
22
24. When editing content type properties…
/admin/structure/types/manage/page
it’s not really obvious
to find ‘Multilingual
support’ among
‘Publishing options’
Enable field
translation for this
content type
24
25. Field translation:
now we can enable/disable
translation of specific fields
Field settings:
“Users may translate this field”
25
26. Now we can translate fields
INSIDE a node!!!
PROFIT!!!
But…
Problem #1:
We cannot translate node title
because title is a special kind of field
Solution:
Use ‘Title’ module to replace the title with a regular
field
26
27. Why problems with title?
• Node title is a special kind of field kept in ‘node’ table
• Unlike other fields, it cannot have multiple values, or
a language of its own
• Title is assumed to have same
27
language as the node
28. ‘Title’ module replaces node title
with a regular field called ‘title_field’
• Like other fields, it can have multiple values with
language specified independently of the node
language
28
29. ‘Title’ module UI: replacing node title with
a regular field
To get back the
original title
field
29
30. Problem #2: Node language issue
• Now, when we can translate each field within a
node separately, it would be most logical for the
node to be language-neutral
• However, we cannot translate a language-neutral
node (translation form is not visible)
• So, we need to specify for this node some
language
30
31. Well, we set node language to English,
so what? Why it’s a problem?
Ukrainian page vs English node
node/1
Title (Eng) Title (Ukr)
(Eng)
Body (Eng) Body (Ukr)
Some field (Eng) Some field (Ukr)
Another field (language-neutral)
To see the Ukrainian content, we switch site language Eng
-> Ukr…
…and the node is no longer visible, because it’s “English”!
31
32. To see ‘English’ node on a Ukrainian page, we have
to disable content filtering by language
/admin/config/regional/i18n/select
• Now, it’s difficult for node translation and entity
translation to coexist in the same site…
• [#1458574 Enable translation button for language-
neutral nodes?] – NOPE. 32
33. Problem #3: Inconvenient form
to edit translated content
• We click “Edit”, to edit the
translated content…
but we go to the “original”
content instead
33
34. Inconvenient form
to edit translated content
To edit the translated content, we
need to click “Translate” -> “Edit
translation”
34
35. Inconvenient form
to edit translated content
• Besides being inconvenient, it can be confusing for
content managers/editors:
– Why the procedure of editing a node depends on its language?
– Why it is more complicated than for “usual” (node-translated)
Drupal sites?
• See discussion in Entity_translation issues:
[#1282018 Improve UX of language-aware entity forms]
(http://drupal.org/node/1282018)
• Hopefully, this issue is to be resolved soon
35
36. New form to edit/translate ET nodes
(under development - v.7.x-1.0-alpha2+97-dev)
Click language button
to edit this language’s version
(this form is more convenient,
but still needs improvement)
36
37. Does Entity translation work with
Views, Menus, Taxonomy, etc.?
Yes, it does!
Some minor issues
37
38. Problem #4: Views and Title field
• Replacing node title with a regular field affects Views
Replaced title
(translatable)
“Old” title
(non-translatable)
• See what title are you adding to your view:
“old” title is NOT translated
38
39. Problem #4: Views and Title field
Original Replace-
title ment title
• For some reason, ‘Link this field to the
original piece of content’ option was not
available for the replacement title 39
40. Solution to Problem #4
• Add Link field AFTER the (replaced) Title
• Rewrite Link field output with ‘[title_field]’
• Exclude Title from display
40
41. Fortunately, we don’t need this trick
anymore since August 2012 – it’s fixed!
Now we can
fff ‘Link this field to the
original entity’
41
42. Some advantages of Entity translation
• Getting rid of parallel nodereferences; switching language
in nodereference-based Views does work
• No need to synchronize fields between nodes: we can
define translatable and non-translatable fields for this
content type
• It’s easy to make URLs language-symmetrical - e.g.
example.com/eng/news/123
example.com/ukr/news/123
• Now it’s simple to translate menu items pointing to nodes
(with node translation, we had to duplicate them – though
D7 allows connecting items in translation sets)
• Cloning nodes should be easier (you have to clone one
node instead of a system of nodes). But it does not work
yet (node_clone module does not support ET).
42
43. Main problems of ET in its current condition
• You cannot publish a node for one language and
hide for another language. It’s either visible for all
languages or invisible for all languages.
(Fix?)
• It’s difficult to combine ET with node translation in
the same site.
• ET is generally less convenient for asymmetrical
sites.
44. Some advantages of node translation
• It makes more sense when content in different
languages is not equivalent (e.g. some nodes are
not translated)
• It’s easier to define language-dependent
permissions (node-level access rights vs field-
level access rights) – e.g. when you have different
teams of content managers for different languages
44
45. Entity translation: Conclusions
• Yes, it works
• Yes, there are some issues – but not critical
• Yes, you can already use it
• You should understand pros and cons
• And you can help improve it
45
46. References
1. Multilingual Content in Drupal 7 & 8 at DrupalCon Munich (by
Suzanne Kennedy)
http://www.slideshare.net/evolvingweb/multilingual-content-in-
drupal-7-8-at-drupalcon-munich
2. Drupal.org community documentation – Entity translation
http://drupal.org/node/1280362
3. Entity translation form – issue discussion
http://drupal.org/node/1282018
4. Drupal 7's new multilingual systems compilation (by Gábor Hojtsy)
http://hojtsy.hu/multilingual-drupal7
5. Drupal 7 Multilingual: What's new in i18n (by Suzanne Kennedy)
http://www.evolvingweb.ca/story/drupal-7-multilingual-whats-new-
i18n
46