Multilingual Site Building with Drupal 7 at Drupal Camp NYC 10

Editor's Notes

• #2: \n
• #3: Intro: Multilingual websites are complicated, and a great deal of the complication comes from the fact that there are lots of different models for building a multilingual website.\n\nThink about how many multilingual websites you've experienced. Maybe the website is completely multilingual, but comments are in English only. Maybe you switch the language of the site and half the content disappears. Maybe all the translations are out-of-date all the time. Maybe the blog only gets updated in one language.\n\nMaybe the structure of menus and blocks are identical in all languages, or maybe they're different.\n\nMaybe you're dealing with a very international website, where language is tied  to a country and things like time zones and local legal constraints.\n\nMaybe the content in each language is completely different, with no language switcher.\n
• #4: \n
• #5: Everything is identical in all languages.\n\nThe menu are perfectly symmetrical. \n\nEach taxonomy term has a translation\n\nContent isn't published until it's been translated into the other six languages.\n\nEven all the paths have to be translated.\n
• #6: Is the content symmetric across languages? \n\nWill content get updated in all languages at the same time?\n\nAre the menu structures the same, or different?\n
• #7: Community website. \n\nTranslation are contributed one by one.\n
• #8: If there is no translation, do you show untranslated content?\n\nIn some cases yes: for example multilingual audiences (Node One). Comments that have value even if they're in a different language.\n
• #9: In some cases, language = location. You want to show particular content/settings based on language.\n\nIn these cases, switching the language of the site might also trigger location-based changes. For example, the default timezone might be different. Legal messages, etc. might also change.\n\nFor Travelocity website, the default language was associated with a domain. But for other websites, you would want to only offer that language.\n
• #10: What language do the translators speak?\n\nAre translators entering content through the UI, or \nare translations done separated and put into Drupal via a script or separate administrator?\n
• #11: Today, we're going to talk about multilingual sites with translation. But \n\nLayers of multilingual websites:\n\nLocale:\nInstall languages\nTranslate user interface strings\nFlag nodes with a language\nLanguage switcher\nLots more (date handling, RTL, user's preferred language, field titles)\nLanguage negotiation\n\nContent Translation:\nAssociates a set of node translations\nProvides a 'translate' tab for nodes\nFlags translations that are out-of-date\n\ni18n:\nVariables (site title, slogan)\nBlocks, Menus, Taxonomy Terms\nContent\nField Data (help text, default text)\nPaths\nExtra Features for Node Translation\nContent Selection\n\n\nAnd later on in this presentation, I'll also talk about the Entity Translation module.\n
• #12: \n
• #13: \n
• #14: User Interface Strings\n(Text strings in code) \nGreen link: see top Brasil hotels\n\nUser-entered settings\nSite Slogan: (Variable)\n\nContent:\nThe article text, image, title\n\nSettings entered by Users\n(i.e. settings like the block titles)\n\nContent\nNodes, Entities\n\nTextgroups\nMenu Items\n
• #15: \n
• #16: \n
• #17: \n
• #18: \n
• #19: \n
• #20: \n
• #21: \n
• #22: Installing + Configuring Language \n\nLanguage configuration page, under 'Regional and language'.\n\nChoosing a default language is really important. Changing this can cause problems.\n\nWhat language fallback will be used (what language will untranslated content appear in?) \n
• #23: Installing + Configuring Language \n\nLanguage configuration page, under 'Regional and language'.\n\nChoosing a default language is really important. Changing this can cause problems.\n\nWhat language fallback will be used (what language will untranslated content appear in?) \n
• #24: Language negotiation is provided by the locale module to detect which language the site should display.\n\nSo for a community site like the one we're talking about, you might choose:\n\nURL\nUser\nBrowser\n\nURL first, means the user can always override the language by using, say, the language switcher.\n\nSecond, User. So when the user logs in, the user's language will be selected.\n\nThird, browser. So if the user arrives at the homepage for the first time, doesn't have an account or a selected language, the browser lang will be chosen.\n
• #25: \n
• #26: \n
• #27: Frontpage might need to be a multilingual variable, if it points to a node in a particular language.\n
• #28: Multilingual variables are provided by the i18n module. \n\nVariables are Drupal settings in the systems table.\n\nAll multilingual sites will have some multilingual variables, but only a selection of them.\n\nYou can see that this config page provides very granular control for which are enabled.\n\nAfter you've selected which variables need to be multilingual, you need to go and add the variables for each language through the UI.\n
• #29: All multilingual sites will have some multilingual variables, but only a selection of them.\n\nYou can see that this config page provides very granular control for which are enabled.\n\nAfter you've selected which variables need to be multilingual, you need to go and add the variables for each language through the UI.\n
• #30: Example: The name of the site should always be translated (I think). So a simple website like Evolving Web's brochure site would have just a couple multilingual variables (title, slogan, frontpage is a common one).\n\nFor our use case: Our German contributors and members are generally located in Europe,  so we can set the default time zone for these users to be CET (Central European Time).\n\nWe should turn on translation for the 'Time zone for new users' variable.\n\nUseful for some sites, not others.\n
• #31: \n
• #32: The translate interface UI allows you to translate text groups, built-in text strings.\n
• #33: The translate interface UI allows you to translate text groups, built-in text strings.\n
• #34: The translate interface UI allows you to translate text groups, built-in text strings.\n
• #35: \n
• #36: \n
• #37: \n
• #38: In Drupal 7, there are two methods of content translation. Translation at the node level is provided by the Content Translation module and translation at the field level is provided by the Entity Translation module. \n
• #39: You can translate different types of content differently, because the method of translation is selected on a per content type basis.\n
• #40: \n
• #41: Targets different audiences\n\nDifferent set of comments\n\nDifferent menu structure (maybe in one language there is a flat menu structure, and in other languages there is a hierarchy)\n
• #42: In Drupal 7, there are two methods of content translation. Translation at the node level is provided by the Content Translation module and translation at the field level is provided by the Entity Translation module. You can translate different types of content differently, because the method of translation is selected on a per content type basis.\n
• #43: In Drupal 7, there are two methods of content translation. Translation at the node level is provided by the Content Translation module and translation at the field level is provided by the Entity Translation module. You can translate different types of content differently, because the method of translation is selected on a per content type basis.\n
• #44: Non-symmetric meus\n
• #45: For some types of content, this node-per-language model is really hard to work with.\n\nSome types of content have language-independent features that we don't want to duplicate by creating multiple nodes.\n
• #46: If the content itself should be language independent, and only particular fields should be translated (i.e. description, etc.). \n\nThis is particularly useful when you really only want 1 node (i.e. an event that has to be scheuled and has sign-upd data around it, a node that receives votes, a node that gets put in a particular order). Also useful for content where we have thousands and thousands of nodes\n\nRather than syncing all of this data and storing for each node, just store it once and translate fields as necessary.\n\nNote: Need to deal with title translation separately, since the title is not a field.\n\nNote: Things like 'taxonomy terms' as fields, if you mark them as 'allow users to translate this field', doesn't replace i18n taxonomy translation. Just allows the user to select different terms per language, not to localize terms.\n\nProducts\nIssues\nGroups\n
• #47: If the content itself should be language independent, and only particular fields should be translated (i.e. description, etc.). \n\nThis is particularly useful when you really only want 1 node (i.e. an event that has to be scheuled and has sign-upd data around it, a node that receives votes, a node that gets put in a particular order). Also useful for content where we have thousands and thousands of nodes\n\nRather than syncing all of this data and storing for each node, just store it once and translate fields as necessary.\n\nNote: Need to deal with title translation separately, since the title is not a field.\n\nNote: Things like 'taxonomy terms' as fields, if you mark them as 'allow users to translate this field', doesn't replace i18n taxonomy translation. Just allows the user to select different terms per language, not to localize terms.\n\nProducts\nIssues\nGroups\n
• #48: Language Independent:\nDate\nSign-ups (Flags)\nEvent Type (Taxonomy)\n\nTranslated:\nTitle\nBody\n
• #49: Language Independent:\nDate\nSign-ups (Flags)\nEvent Type (Taxonomy)\n\nTranslated:\nTitle\nBody\n
• #50: If the content itself should be language neutral, and only particular fields should be translated (i.e. description, etc.). \n\nThis is particularly useful when you really only want 1 node (i.e. an event that has to be scheuled and has sign-upd data around it, a node that receives votes, a node that gets put in a particular order). Also useful for content where we have thousands and thousands of nodes\n\nRather than syncing all of this data and storing for each node, just store it once and translate fields as necessary.\n\nNote: Need to deal with title translation separately, since the title is not a field.\n\nNote: Things like 'taxonomy terms' as fields, if you mark them as 'allow users to translate this field', doesn't replace i18n taxonomy translation. Just allows the user to select different terms per language, not to localize terms.\n
• #51: If the content itself should be language neutral, and only particular fields should be translated (i.e. description, etc.). \n\nThis is particularly useful when you really only want 1 node (i.e. an event that has to be scheuled and has sign-upd data around it, a node that receives votes, a node that gets put in a particular order). Also useful for content where we have thousands and thousands of nodes\n\nRather than syncing all of this data and storing for each node, just store it once and translate fields as necessary.\n\nNote: Need to deal with title translation separately, since the title is not a field.\n\nNote: Things like 'taxonomy terms' as fields, if you mark them as 'allow users to translate this field', doesn't replace i18n taxonomy translation. Just allows the user to select different terms per language, not to localize terms.\n
• #52: If the content itself should be language neutral, and only particular fields should be translated (i.e. description, etc.). \n\nThis is particularly useful when you really only want 1 node (i.e. an event that has to be scheuled and has sign-upd data around it, a node that receives votes, a node that gets put in a particular order). Also useful for content where we have thousands and thousands of nodes\n\nRather than syncing all of this data and storing for each node, just store it once and translate fields as necessary.\n\nNote: Need to deal with title translation separately, since the title is not a field.\n\nNote: Things like 'taxonomy terms' as fields, if you mark them as 'allow users to translate this field', doesn't replace i18n taxonomy translation. Just allows the user to select different terms per language, not to localize terms.\n
• #53: Only fields can be translated using Entity Translation. Unfortunately, not everything on a node is a field.\n\nFor example, the title is node field.\n\nLuckily, for field, there's a contributed module called 'Title' that allows you to convert the title to a field.\n\nFor other elements, like menu items, author. These are still not fields. This is why you would want to use content translation for nodes for which these need to be different per language.\n
• #54: Only fields can be translated using Entity Translation. Unfortunately, not everything on a node is a field.\n\nFor example, the title is node field.\n\nLuckily, for field, there's a contributed module called 'Title' that allows you to convert the title to a field.\n\nFor other elements, like menu items, author. These are still not fields. This is why you would want to use content translation for nodes for which these need to be different per language.\n
• #55: Only fields can be translated using Entity Translation. Unfortunately, not everything on a node is a field.\n\nFor example, the title is node field.\n\nLuckily, for field, there's a contributed module called 'Title' that allows you to convert the title to a field.\n\nFor other elements, like menu items, author. These are still not fields. This is why you would want to use content translation for nodes for which these need to be different per language.\n
• #56: Unchecking this setting allows you to display comments in all languages for nodes with entity translation.\n
• #57: Unchecking this setting allows you to display comments in all languages for nodes with entity translation.\n
• #58: You can configure which of these entities has entity translation enabled.\n
• #59: You can configure which of these entities has entity translation enabled.\n
• #60: For example, if you make users translatable entities, you can translate them via a translate tab.\n
• #61: Synchronize Translations is a submodule of the Internationalization module (i18n). This module allows you to synchronize certain fields across languages when translating nodes with the Content Translation module. While it provides some of the same results, it works very differently from the entity translation module. A node is still created in each language, but when a synchronized field is updated in one language, all the node translations are updated to use the same field.\n\nWhen using Drupal 6, this provided a good way to deal with situations when node elements needed to be the same across languages (i.e. author, taxonomy terms, etc). However, it doesn't resolve problems like synchronizing the status of a node (when using the Flag module) or synchronizing a list of signups for an event content type.\nFor Drupal 7, Synchronize translations is useful for situations when you want to maintain two separate nodes (for example, because you want the nodes to appear in different places in the menu), but you still want to synchronize certain fields.\n
• #62: Only fields can be translated using Entity Translation. Unfortunately, not everything on a node is a field.\n\nFor example, the title is node field.\n\nLuckily, for field, there's a contributed module called 'Title' that allows you to convert the title to a field.\n\nFor other elements, like menu items, author. These are still not fields. This is why you would want to use content translation for nodes for which these need to be different per language.\n
• #63: Only fields can be translated using Entity Translation. Unfortunately, not everything on a node is a field.\n\nFor example, the title is node field.\n\nLuckily, for field, there's a contributed module called 'Title' that allows you to convert the title to a field.\n\nFor other elements, like menu items, author. These are still not fields. This is why you would want to use content translation for nodes for which these need to be different per language.\n
• #64: Only fields can be translated using Entity Translation. Unfortunately, not everything on a node is a field.\n\nFor example, the title is node field.\n\nLuckily, for field, there's a contributed module called 'Title' that allows you to convert the title to a field.\n\nFor other elements, like menu items, author. These are still not fields. This is why you would want to use content translation for nodes for which these need to be different per language.\n
• #65: Only fields can be translated using Entity Translation. Unfortunately, not everything on a node is a field.\n\nFor example, the title is node field.\n\nLuckily, for field, there's a contributed module called 'Title' that allows you to convert the title to a field.\n\nFor other elements, like menu items, author. These are still not fields. This is why you would want to use content translation for nodes for which these need to be different per language.\n
• #66: Only fields can be translated using Entity Translation. Unfortunately, not everything on a node is a field.\n\nFor example, the title is node field.\n\nLuckily, for field, there's a contributed module called 'Title' that allows you to convert the title to a field.\n\nFor other elements, like menu items, author. These are still not fields. This is why you would want to use content translation for nodes for which these need to be different per language.\n
• #67: New UI for translation of certain text groups (for blocks, menus, taxonomy)\n\nUses textgroups\n
• #68: Only fields can be translated using Entity Translation. Unfortunately, not everything on a node is a field.\n\nFor example, the title is node field.\n\nLuckily, for field, there's a contributed module called 'Title' that allows you to convert the title to a field.\n\nFor other elements, like menu items, author. These are still not fields. This is why you would want to use content translation for nodes for which these need to be different per language.\n
• #69: \n
• #70: Still doeesn't work with the contxt module, since that alters how blocks are rendered.\n\nImproved UI in Drupal 7!\n\nSee Save + Translate, takes you directly to a page where you can add translations of the block.\n\nBlock translation UI in the block management interface, rather than interface translation UI.\n\nMultilingual settings on a per block basis, so you can be granular about how blocks are configured.\n
• #71: Still doeesn't work with the contxt module, since that alters how blocks are rendered.\n\nImproved UI in Drupal 7!\n\nSee Save + Translate, takes you directly to a page where you can add translations of the block.\n\nBlock translation UI in the block management interface, rather than interface translation UI.\n\nMultilingual settings on a per block basis, so you can be granular about how blocks are configured.\n
• #72: If a block needs to appear for some languages of the site and not others, you can make the block  'Make this block translatable', and then flag it to appear only in the relevant languages.\n\nFor example, the first block on this page 'Aidez-nous a traduire le site web' is targeted at French and German users, so I've only selected those languages for that block.\n\nThe second block only targets French users, so I didn't make it translatable, and set it to only display in French. \n\nThe final block appears in all languages and is translatable.\n
• #73: Only fields can be translated using Entity Translation. Unfortunately, not everything on a node is a field.\n\nFor example, the title is node field.\n\nLuckily, for field, there's a contributed module called 'Title' that allows you to convert the title to a field.\n\nFor other elements, like menu items, author. These are still not fields. This is why you would want to use content translation for nodes for which these need to be different per language.\n
• #74: \n
• #75: New UI for translation of certain text groups (for blocks, menus, taxonomy)\n\nUses textgroups\n
• #76: New UI for translation of certain text groups (for blocks, menus, taxonomy)\n\nUses textgroups\n
• #77: Only fields can be translated using Entity Translation. Unfortunately, not everything on a node is a field.\n\nFor example, the title is node field.\n\nLuckily, for field, there's a contributed module called 'Title' that allows you to convert the title to a field.\n\nFor other elements, like menu items, author. These are still not fields. This is why you would want to use content translation for nodes for which these need to be different per language.\n
• #78: \n
• #79: \n
• #80: New UI for translation of certain text groups (for blocks, menus, taxonomy)\n\nUses textgroups\n
• #81: New UI for translation of certain text groups (for blocks, menus, taxonomy)\n\nUses textgroups\n
• #82: New UI for translation of certain text groups (for blocks, menus, taxonomy)\n
• #83: \n
• #84: \n
• #85: \n
• #86: New UI for translation of certain text groups (for blocks, menus, taxonomy)\n
• #87: New UI for translation of certain text groups (for blocks, menus, taxonomy)\n
• #88: The Drupal 8 Multilingual Initiative, let by Gábor Hojtsy, aims to move the features provided by the Entity Translation module into core. Work is underway to improve other aspects of Drupal's language capabilities for Drupal 8.\nMeanwhile with Drupal 7, we have more options for translating content than ever before. The Entity Translation module provides an elegant solution for translation on the field level, while Content Translation still gives us the option of translating nodes. While all these options might be confusing, they allow us to build more sophisticated multilingual sites in Drupal than ever before.\n
• #89: If you're interested in learning more about multilingual site building, I encourage you to vote for this session that Florian Loretan and I have put together for DrupalCon Denver.\nEven if you're not attending the camp, it'd be great to have a session on this at the North American conference so we can get more organizations using Drupal's multilingual features and seeing Drupal as a great framework for creating multilingual site infrastructure.\n
• #90: \n