Free Trial

Safari Books Online is a digital library providing on-demand subscription access to thousands of learning resources.

  • Create BookmarkCreate Bookmark
  • Create Note or TagCreate Note or Tag
  • PrintPrint

Nodes

Nodes For the majority of Drupal websites, most content exists in nodes. These nodes come in different shapes and sizes as defined by a node's content type. The information, if any, that needs translating for a particular node depends on how the content is used, so there is no cookie-cutter formula for creating multilingual nodes. You will need to decide how to deal with translation for each and every content type. In this section, we will go over the different approaches for multilingual node content. We will work with concrete examples to help you figure out the methods to implement on your own site. Enabling multilingual support For the exercises, it's useful to have a few content types to work with. If you are using the demo website, you have several to choose from including Article, Blog entry, Basic page, and Drupal Book. The first three are pretty self-explanatory. Drupal Book is a custom content type for displaying a particular Drupal book title. For simplicity, Drupal Book nodes are not configured for e-commerce, but check out kristen.org/drupal7-i18n-commerce to learn about internationalization for the Drupal Commerce module. To enable multilingual support on your site, follow these steps: Choose a content type and go to its main config page (for example, for Blog entry, go to Structure | Content types | Blog entry | Edit).Now click on the Publishing options tab towards the bottom of the form and you will see the following options since the Locale module is enabled: Choose the Enabled radio button in the Multilingual support section and then click on Save content type. Now any node of this content type can have a language associated with it. If I edit a Blog entry node, I now have a Language field on my node edit form. The Language drop-down includes all enabled site languages as well as a Language neutral option. Choose Language neutral if you have language-independent content. For example, if you have an Image content type with an image field in it, then an Image node might not have linguistic content and could be set as Language neutral. Node translation model In previous versions of Drupal, content translation was done by copying the source node for each language. The source node and its associated translated nodes together form a translation set such as the grouped nodes shown in the following figure: The node translation model is still available for Drupal 7. Note that for Drupal 8, the current plan is to combine the node translation model and field translation model, discussed later in this chapter, to unify the architecture. Node translation might be useful when your content will be mostly or fully translated. For example, if you have a blog post or an article, it is likely that you'll want to translate everything in the text except perhaps meta information such as the author's name and the date of the post. There might be common fields that the nodes should "share" such as an image or a video, but those shared fields can be handled with some configuration. Another good reason to use node translation is if you want to track each node separately, for example, if you want users to vote on different translations of an article, or if you want them to flag translated blog posts, for instance, "I like this!" or "Bad translation!" You might even want a different workflow for each node to allow published nodes and unpublished nodes within the same translation set. Conversely, you should now have a better idea of when you don't want to use the node translation model. Typically this is the case if you have a minimal number of fields that need translating or if you want to make sure to track the node as one object for whatever purpose (voting, flagging, workflow, tracking, and so on). For these use cases, we will look at some examples in the field translation section later in this chapter. Configuring node translation We need to configure a few different things to get our node translation set up. In this section, we'll enable the required modules, configure our content types, and change some node display options. Oh, and we'll translate content too! Content type settings Let's start with configuring our content type by following these steps: Enable the core Content Translation module.If we go back to our content type configuration page (for example, for Blog entry, go to Structure | Content types | Blog entry | Edit) and click on the Publishing options tab, we have a new Multilingual support option: Select the Enabled, with translation radio button and click on Save content type.Now if you view a node page for that content type, you'll see a new handy Translate tab: Tip If you don't see a Translate tab, then most likely you have that node's language set as Language neutral. Edit the node, choose a language, and save it, so that the Translate tab will appear. Click on the Translate tab and you will be shown a summary of the current translations for that node. To translate the node, click on add translation for a particular language. Since we already configured the interface in Chapter 2, Setting up the Basics: Languages, UI Translation, and System Settings, we will see the translated UI strings on the node edit page. For example, I see the German Drupal interface when adding a translation for German: Node display options By default, translation links are added to the node links for any available translations (for example, English in the following screenshot): The decision to show translation links on teasers and node view pages is a matter of preference. These links can improve usability if you have a small number of languages, but the UI can look ugly if you have too many. To turn translation links off completely, follow these steps: Install the Multilingual Content module from the Internationalization package (drupal.org/project/i18n).Flush the cache and go to Configuration | Regional and language | Multilingual settings | Node options.Select Hide content translation links and click on Save configuration.On this page, you can disable the Switch interface for translating option if desired. You can also set the default language for content types that have multilingual support disabled. This can be set to The site's default language or to Language neutral depending on the type of content you expect to store: The Multilingual Content module from the Internationalization package adds a Language field to the content types. Typically you won't want this Language field shown when viewing a node. It can be hidden by performing the following steps: Go to the content type's Manage display page (for example, for the Blog entry content type, this is at Structure | Content types | Blog entry | Manage display).Choose Hidden for the Language field.Click on Save.Click on the small Teaser sub-tab and repeat. New and existing translations Now you can go back and create more translations using the same process: View the node page and click on the Edit tab.Choose language and click on the Save button.Click on the Translate tab.Click on the add translation link, translate the content, and click on Save. If you have an existing German node which should be the translation of an existing English node, then clicking on the add translation link won't help you because both nodes already exist. How do we link these nodes together in a translation set? Fortunately the Internationalization package comes to the rescue again: Click on the Translate tab and you'll see a useful form at the bottom of the page since the Multilingual Content module is installed.To use an existing node, just type the node title into the auto-complete text field to find it.Don't forget to click on Update translations after you find the right nodes! Synchronizing shared fields There are times when a content field is not dependent on language and doesn't need translating. For example, an image might be language-independent and could be used for all nodes in a translation set. The simplest way to deal with these types of fields is to use the Synchronize Translations module which is part of the Internationalization package. Install the Synchronize Translations module (drupal.org/project/i18n) and then navigate back to your content type configuration page. In my case, I'll go to the Article content type at Structure | Content types | Article | Edit.You will now see a Synchronize translations tab at the bottom of the form.Click on the Synchronize translations tab.Choose the fields you want to keep in sync.Click on Save content type. Note Be very careful when choosing the fields you want to synchronize. For example, it is highly unlikely you will want to select the Body field. Say you do select it and create an English node with body text. If you then translate the node for German and change the body text, the original English body text would be wiped out and replaced with the one you provided for the German node. This is probably not what you want to happen! For this example, I edited the Article content type and chose a number of fields to be in sync, including a custom Image field. Now when I edit any Article nodes, the image will be shared across all nodes in a translation set. Try it for yourself! Extra content type options The Internationalization module package is a treasure-trove of useful goodies. To see a few more settings from the Multilingual Content module, navigate to your content type configuration page (for example, Structure | Content types | Article | Edit). Then click on the Multilingual settings tab to see some new options. These are the extended language options: Set current language as default for new content: This is a good option to enable for all multilingual content types. If enabled and you are navigating the site in Polish, then Polish will be auto-selected for your node's language when creating content.Require language (Do not allow Language Neutral): This one is pretty self-explanatory. When you create a node, the Language neutral option will not be available in the Language drop-down list. Therefore you'll need to choose a specific language. This option is good for any content types that must be translated.Lock language (Cannot be changed): If you enable this setting, then the node's language cannot be changed after the node is created. This option might be useful if you are setting your language correctly each and every time, but it will end up being a pain if you don't! Here are some options for extended language support: Normal: When you edit content, only the site's enabled languages will be available in the Language field. Most sites should stick with this setting.Extended: All of the defined languages will be listed in the Language drop-down whether enabled or not. This option is useful when you want some languages for the UI but need more languages for the content. For example, you should use this option if you are staging content for a language that shouldn't be made public yet.Extended, but not displayed: Same as the Extended option, but translation links will not be shown for disabled languages. Field translation model In the previous sections, we explored why we might use the node translation model for certain content types. When that method is not appropriate, we can use field translation instead. The field translation model uses one node rather than a set of nodes where individual fields are translated as needed, as illustrated next for the Title and Body fields. Entity fields were introduced in Drupal 7, so field translation is not available in earlier versions of Drupal. As mentioned previously, the Drupal 8 Multilingual Initiative is investigating how to combine the node and field translation models together for Drupal 8. Field translation is useful when you have a minimal number of content fields to translate or when you need to maintain one multilingual node. For example, a product content type typically has fields such as price, images, and manufacturer that probably should not be translated. For a product node, translatable information would likely include title, body, and similar descriptive text, so those specific fields should be configured for translation. A product content type is a good candidate for the field translation method for other reasons as well. When someone buys a product, it is tracked. For example, we can find out how many people bought the product. If we use node translation for products, then our tracking is per node. We wouldn't know how many people bought a particular product, but instead would have the total for the number of people who bought the product using the German interface, the French interface, and so on. This isn't usually what we want. Other examples of when field translation makes sense include events and organic groups. When someone signs up for an event, it is important to track the event data in one node. For organic groups, the main group node is the key to membership, so it would be problematic to have multiple nodes. Field translation is the best solution when you have these types of language-unaware node relationships. Configuring field translation As with node translation, we need to configure several things before we start using field translation. In this section, we will enable the necessary modules, configure our entity and content type settings, and then translate our content. Entity settings To configure your entity settings, follow these steps: Install the Entity Translation module ( drupal.org/project/ entity_translation).Entity Translation adds a new Content language detection section at Configuration | Regional and language | Languages | Detection and selection. Navigate to that page and update the settings so that the Content language detection section matches the User interface text language detection section (rearrange the items as needed and make sure the same items are checked or unchecked).Enable the Interface method and move it to the top. This option will try to use the interface detection settings when possible, but it isn't always reliable. This is why you should match the interface detection section options as well.Click on Save settings when you're done. Now you need to replace your current language switcher block called Language switcher (User interface text) with the new Language switcher (Content) block. If you don't change the block, the switcher links won't be correct.To enable your nodes for translation, you now have a new Entity Translation config page at Configuration | Regional and language | Entity translation. We can stick with the default entity settings since we are focusing on node content at the moment. We'll look at the other entity options later in this chapter. Content type settings When configuring our content type settings, we will need to choose a content type for field translation and then proceed with the following steps: Go to your content type config page (for example, edit Drupal Book at Structure | Content types | Drupal Book | Edit), click on the Publishing options tab, and you'll see a new option for Multilingual support: Choose Enabled, with field translation and click on Save content type. Note that for earlier module versions, the option is Enabled, with entity translation. Now we need to decide which fields to translate. Drupal Book has a number of fields including Title, Image, Description (Body), and Drupal Version: An interesting thing about the Title field in Drupal 7 is that it's technically not a real "field" (it is considered a "property"). This is a problem when using field translation because we want to translate the node's Title. The workaround is to install the Title module ( drupal.org/project/title) and the Entity API module ( drupal.org/project/entity). Install both of those now and then go to the content type's Manage fields page.You'll see a replace link for the Title. Click on replace, select the Replace title with a field instance checkbox, and click on Save settings: The Title module will do some magic and then the Title will be transformed into a bona fide Text field. One oddity is that the new Title field will show up on the node view page (you'll have two titles!), so it needs to be hidden. Go to the Manage display page for your content type, choose<Hidden> for the Title, and click on Save: For Drupal Book, let's configure the Description (Body), so it can be translated. The Title module will enable translation for the Title field for us. Go back to the Manage fields page.Click on edit for the Description (Body) field and the bottom of the form will look similar to the next screenshot. Note that it will say BODY FIELD SETTINGS when editing a Body field that has not been renamed. If you don't have content yet, there will be a Users may translate this field checkbox, otherwise, there will be an Enable translation link. Select the checkbox and save the settings, or click on the link. If there is content, a Disable translation link will be available if you need to turn off translation.Repeat this process for all fields you want to translate. Tip Author and status are not "fields" and cannot be translated using field translation. If you need a different author or workflow per translation, you'll need to use node translation and the Synchronize Translations module similar to what we did earlier in this chapter. Translating content Now that the fields have been configured, we can translate our content. Edit an existing node or create a new one, set its language to the default language, and save the node. The Translate tab will be available just as it was when we used the node translation model. Click on Translate and the UI will look familiar. To add translations, just follow the same process as before: Click on the add translation link.Translate content and click on the Save button.Repeat for each language. Using the language switcher Because of the way field translation works, notice that all languages are "available" in the language switcher for our node even when translations are actually missing. These duplicate pages affect the site's SEO, which will be discussed in Chapter 5, Panels, SEO, and More!. Another thing to remember is that, for field translation, we are using one node. So, if you click on any language in the language switcher and edit the node, you are actually editing the same node, no matter what the interface language is. This is very important to keep in mind, particularly if you are using both node translation and field translation models. It can become confusing at times if you aren't paying attention. Let's recap: When you use the language switcher for node translation, you will be viewing a different node. In that case, if you edit the node, you'll see the node edit page for the translated content. Saving the node will affect the translated node and not the source node (except for synchronized fields). Translated content can be handled with this method or via the Translate tab process.When you use the language switcher for field translation, you will be viewing the same node but the translated fields will show up to match your chosen language. If you edit the node, you'll see the node edit page for the source node content (the only node). To translate content, you must click on the Translate tab and use that process. Note At the time of writing, there is an open Entity Translation issue to allow field translation via the node edit page ( drupal.org/node/1282018).

  

You are currently reading a PREVIEW of this book.

                                                                                                                    

Get instant access to over $1 million worth of books and videos.

  

Start a Free Trial


  
  • Safari Books Online
  • Create BookmarkCreate Bookmark
  • Create Note or TagCreate Note or Tag
  • PrintPrint