View stunning SlideShares in full-screen with the new iOS app!Introducing SlideShare for AndroidExplore all your favorite topics in the SlideShare appGet the SlideShare app to Save for Later — even offline
View stunning SlideShares in full-screen with the new Android app!View stunning SlideShares in full-screen with the new iOS app!
18 letters omitted 10 letters omitted L ocalizatio n L10n These abbreviations are used in the names of Drupal modules, such as “i18n” or “L10n_client”
If Drupal nodes were designed as multilingual from the very beginning …
Title (lang1) Title (lang2) 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
However, Drupal nodes are unilingual . i18n is an external feature.
node/1 (unilingual) lang1
Some file attached Another file attached node/2 (unilingual) lang2 Some file attached Another file attached Drupal i18n system: I hereby declare node/1 and node/2 to be translations of each other comments comments Title Body Some field Another field Title Body Some field Another field
Drupal uses both approaches (depending on the object type), so improvements of multilang support proceed in two ways:
Making objects “more multilingual”
Improving the system of i18n-related connections between unilingual objects
Each approach has its advantages and difficulties
Until recently, approach to nodes was only “from outside”
Some problems caused by this approach will be demonstrated below
No field-level language attributes: Why it can be a problem? Example 1
Image field node/2 lang2 Image field translation synchronization Title Body Title Body
No field-level language attributes: Why it can be a problem? Example 2
You need to synchronize nodereferences
node/3 (en) event info node/4 (ru) event info node/1 (en) location info node/2 (ru) location info translation translation nodereference nodereference
Problem with multilingual views based on nodereference
ru/events/by-location/ Распределение со бытий по месту проведения:
ru/events/by-location/37 Список событий в Кишинёве
en/events/by-location/ Events grouped by locations :
en/events/by-location/36 List of events in Chişinău “ Chişinău ” (node/36) and “ Кишинёв ” (node/37) are different nodes, so when you switch language EN -> RU while viewing the “ List of events in Chişinău ” you will see an empty list instead of “ Список событий в Кишинёве ” . en ru en ru
node/1 Base node node.nid=1 node.language=‘ en ’ node.tnid= 1 node/2 Translated node node.nid=2 node.language=‘ uk ’ node.tnid= 1 node/3 Translated node node.nid=3 node.language=‘ ru ’ node.tnid= 1
And now something really new… We need to use some contributed modules However, D7 has NO built-in interface for translatable fields D7 core has built-in support for field languages!!! (via its new Field API)
Q: Can I build a multilingual site using only the core D7 functionality?
A: A very simple site – yes, but for more complex things you’ll need the i18n.module. i18n helps you handle multilingual blocks, menus, views, synchronization of items between nodes, and so on.
Enabling multilingual variables in i18n/D6: add their names ( site_name , site_footer , theme_settings , etc.) to the settings.php file $conf['i18n_variables'] = array( // Site name, slogan, mission, etc.. 'site_name', 'site_slogan', 'site_mission', 'site_footer', 'anonymous', // Different front page for each language 'site_frontpage', // Primary and secondary links 'menu_primary_links_source', 'menu_secondary_links_source', // Contact form information 'contact_form_information', // For theme variables, read more below 'theme_settings', 'theme_garland_settings', );
i18n/D7 does not work this way anymore Now multilingual variables are controlled via “Multilingial settings – Variables” menu (Depends on the new variable.module )
Multilingual variables A very convenient link to switch languages (especially if there is no language switcher in the admin theme)