Creating a website with community content is great, but what if some or all of your community doesn’t read or write English? It’s a big world, and only about 6% of it speaks English as a native language. Multilingual sites allow you to reach out to your community members and let them feel comfortable contributing. Having multiple languages is not as simple as having users post content in whichever language they like. There are other things to consider, like navigation, date formatting, and help text. And what about having the same post available in multiple languages, and easily navigating between them? Once you start thinking about it in detail, there is a lot of ground to cover. Luckily, Drupal core and a few contributed modules have done a lot of that hard work for us so we can concentrate on building our community and content.
The two main concepts for multilingual sites are internationalization, often abbreviated i18n, and localization, often abbreviated l10n. Internationalization is the underlying structure that allows software to be adapted to different languages, and localization is the process of actually translating the software for use by a specific locale. Localization is not necessarily limited to just translating text, but also encompasses changing things like date formats and currency.
Drupal has made great strides toward building a better internationalization system inside Drupal core that makes localization much easier. Core does not quite provide us with all of the tools we need to completely localize a site, but there are contributed modules ready to fill the gaps.
This chapter introduces the following modules:
- Locale (core)
Provides interface for translating and importing translations for user interface text
- Content Translation (core)
- Localization update
Checks for translation updates from the Drupal translation site and provides an interface to update translations from within your site.
- Localization client
- Internationalization
Allows other elements to be translated, such as menus, blocks, and taxonomy terms
- Variable
Provides an API for registering data for variables (required by Internationalization)
- Book (core)
A module that allows multiple users to collaborate on documentation
- Forum (core)
If you would like to participate in the hands-on exercises in this chapter, install Drupal using the Chapter 8: Multilingual installation profile from the book’s sample code. This will create the example website on your web server. The completed website will look as pictured in Figure 8-1 and at http://multilingual.usingdrupal.com. For more information on using the book’s sample code, see the Preface.
Our client, Blue Peak Fanatics, is an international group that loves to climb mountains. They need a website that will allow everyone to have forums to discuss their shared passion as well as keep a repository of shared knowledge. They would like the site to provide language-specific forums for discussion, and allow members to navigate the site in their preferred language. They will also need an online knowledge base where members can share useful information, and a way to post news about the site. Additionally, they want to allow nonforum content to be translated by group members who know more than one language, so they can all share the accumulated knowledge. They currently have members who speak three different languages—English, Danish, and French—but they would like the ability to add more languages later as the group grows.
Though Drupal core’s default Article content type can easily be used to post news to the front page, other features that the client requires warrant some further discussion.
There are contributed modules available that add integration between Drupal and other forum systems, such as phpBB, but Drupal itself comes with its own simple forum using the built-in Forum module. The Forum module uses regular Drupal core concepts such as taxonomy (for forum containers and forums themselves), nodes (for posts inside a forum), and comments (for replies), which makes it integrate seamlessly with the rest of the website, including Drupal’s translation features.
Another core Drupal module, the Book module enables multiple users to collaborate together in order to create a collection of documentation. Book pages are structured into one or more hierarchies, with previous, next, and up links generated automatically on each page. Each page also provides a “printer-friendly version,” which will create an unformatted page consisting of the content of the current page and any subpages for easy printing or downloading for offline reading.
User interface is the text that is provided by Drupal, both in core and contributed modules. This includes things like form labels, help text, and navigation. Drupal core’s Locale module provides the framework that allows user interface translations. To get the bulk of our localization, we will download translation projects that will supply us with translations of the core user interface. To easily download translations, as well as keep them up-to-date, we’ll use the “Localization update” module. As we add contributed modules, we’ll need to check whether they supply a module-specific translation. The “Localization update” module will help us with this as well. If there are no module translations for our language yet, we are not out of luck, because core also gives us the framework to add and update our own translations as needed within our site. The “Localization client” module uses this framework to add a nice, user-friendly frontend to make translating interface text a breeze.
Locale does not cover every single aspect of user interface text, though, so we will be using the excellent Internationalization (i18n) module to fill in the gaps. The Internationalization module provides us the tools to translate taxonomy, blocks, and certain site variables like the site name and mission statement. In addition to providing extra translation, it also helps us manage our multilingual content.
The final missing piece is translation for all of the user-generated content on the site: forum posts, pages, and so on. Core provides the “Content translation” module to do the heavy lifting. This will allow us to decide which content is translatable, and lets us create multiple versions of each node, each in a different language. It also provides a simple way for users to switch between languages. Again, the Internationalization module will fill out some of the content features.
Drupal core comes with the Locale module, which works with the user interface text and gives you a nice set of tools that let you import existing translations, create or edit your own, or export your site’s translations for use on other sites.
Another really nice feature in Drupal core is support for right-to-left (RTL) languages, such as Arabic or Hebrew. If a language is set as an RTL language, Drupal will automatically flip all of the text so that it reads in the proper direction, as seen with Arabic in Figure 8-2.
Locale handles the translation files and language switching options on the site. Let’s break it down and look at what that means.
A translation is simply a file or collection of files that follows a standardized format. Translation files that follow this format have a special file extension, .po, which stands for “portable object.” A .po file is a simple text file that identifies strings of text and a particular language’s translation of the strings. In Drupal, translations contain a list of all user interface strings in Drupal, along with their translated versions.
Drupal translation .po files are downloaded from http://localize.drupal.org. Here you will find core Drupal translations, along with any contributed module translations that have been created. An important thing to note about the translation projects is that they may be in various states of completion, coverage for contributed modules can be spotty, and sometimes you may not agree with the way something was translated. Not to worry; we’ll show you how to deal with that, too.
While you can manually download the .po files you need and add them to your site, it can quickly become tedious, especially as you add contributed modules to your site. The Localization update module will do this tedious chore for you. It will find the correct files from the Drupal translations server, download them to your site, and install a language, all in one process. You can also use it to check for and download updates to your translations.
Many volunteers have worked hard to translate the Drupal interface into as many languages as possible. You may find that you need to add to or modify the translation you are using. If this happens, Drupal has tools built in to assist you.
When you visit the interface translation page at
Administer→“Site building”→“Translate interface”
(admin/build/translate), you will see that
there is a list of the languages you have enabled, along with a
count and percentage of the number of strings that have already been
translated, as shown in Figure 8-3. As you move through
your site, Drupal will keep track of all the interface strings that
you encounter. It can do this because translatable strings are
identified in the code itself whenever a developer uses a translation function (the t() function). Once you visit a page, all of
the translatable strings will be available for searching and
translation. Visiting the page is an important step that is easy to
forget. If you start searching for words that you know exist on the
site, but you haven’t actually visited the page where they are, your
interface search will come back empty. We’ll look more into
translating in Hands-On: Translating the Interface.
One thing to understand is that any translations you make through the Drupal interface, rather than by importing a .po file, will be stored in the database, not in a file. Drupal has an export feature that will put your translations back into a file format that you can then import into other sites.
Note
If you do translation work on your site, you should definitely consider giving your work back to the community. By giving translations back, you not only help the larger Drupal community, but also yourself, as you will have a larger number of people to test your work and help maintain it.
Every site must have a default language, but how do we get the other languages to display? There are two main core mechanisms for this: the language detection and selection setting, and the language switcher block. After you have installed and enabled at least one other language, the first thing you should do is tell Drupal how to automatically handle multilingual display by configuring the language detection and selection. By default, Drupal will do nothing, and users will need to manually choose their language. You can select from several options, seen in Figure 8-4, which will automatically choose the language based on a variety of available information.
With the URL detection method, Drupal can set the language based on the domain name of the site or by a path prefix. You can choose this in the Configure screen for URL. If you choose to use a separate domain name for each language you will offer, you can assign the domain name to a language in the language settings. For example, you can configure the Danish language to use the domain name http://dk.example.com or even http://foo.example.com. Whenever someone accesses the site using one of these domain names, the language you have set will always be used.
The more common negotiation method is using the path prefix. Again, you can configure the prefix you wish to use. By default, a translation that you install will set its language code as the path prefix identifier. With this setting, Drupal will check the path for a language code directly after the domain name—for example, http://example.com/dk/forum. If Drupal finds a valid code, it will display the language associated with it. You don’t need a prefix for your default language, so that language will be used for all of your “plain” paths, as in http://example.com/forum.
Your users can also set a language preference for themselves, if you enable the User method. The Locale module provides users with a “Language settings” section on their account page, which lets them choose the language for system emails. Once you enable the User detection method, you will see that those settings will then indicate they are also being used for site presentation, as you can see in Figure 8-5. However, this allows only authorized users to pick a language. To give all users a choice, including anonymous users, you can enable a core language switcher block that lists the available languages and will switch the site language as needed.
You can enable as many or as few detection methods as you wish. You can determine the priority for the different methods by reordering them in the table. The method at the top will be used first, and if that one does not provide adequate information to determine the language, Drupal will continue down the list until it finds a method that does. At that point, it will set the language and stop checking.
You can add new translations at any time, but if you wish to use a translation during the installation process as well, you will need to get a translation prior to going through the installer. By default, after you have selected an installation profile, the installer presents the default option to install Drupal in English along with a link to “Learn how to install Drupal in other languages.” That link explains where you can download a translation file, and where you need to place that in your Drupal file structure: in the profiles/standard/translations folder. A much, much easier way to do this is to use the Localized Drupal Distribution to install Drupal. This is a normal version of Drupal that is packaged with the “Localization update” and “Localization client” modules. This will let you choose a new Localized Drupal profile for installation, as shown in Figure 8-6, and then it will present you with a list of languages.
You can then choose which language to use, and the rest of the installation screens will be displayed in that language, as pictured in Figure 8-7. Once you complete the installation of Drupal, the language you selected will be set as the default language for your site.
The first step to using any of Drupal’s multilingual features is installing a translation, so that Drupal has more than one language to choose from. As mentioned previously, you can use a localized distribution so that you install your language during the site installation process. Alternatively, you can add a language after you have installed the site by using the “Localization update” module.
First, in the administrative toolbar, click Modules (admin/modules) and enable the following modules (note that if you installed Drupal with the localization distribution, these will already be enabled):
Core
Locale
Multilingual package
Localization update
In the administrative toolbar, click Configuration→Languages (admin/config/regional/language) under the “Regional and languages” section. Then click the “+ Add language” link, as shown in Figure 8-8, to be taken to the screen shown in Figure 8-9.
Select your language from the “Language name” select list (in this case, we are adding Danish) and click the “Add language” button.
The translation files will be imported from the Drupal.org server into your site, and you will see an “Updating translation” screen with a progress bar, as shown in Figure 8-10. Once the import is completed, you will see a message that outlines all of the updates you have imported and indicates that the site successfully imported the translation.
You can repeat the language selection for each language that you wish to have available on your site. In our examples throughout the chapter, we have also installed French, using the same process as we did to install Danish. When done, the Languages settings page will list all of the site languages in a table that lets you take various actions, such as disabling a language, changing the site default language, affecting the order in which the languages are displayed in lists, and deleting them altogether. Figure 8-11 shows this table with our site’s three languages: Danish, English, and French. English is marked as the default language, which means it will be used as the fallback language when there is no language specified either through the language negotiation settings or a logged-in user’s personal settings under his “My account” page, as we saw in the section Language switching. The crosshair icon at the beginning of each line in the table will let you drag and drop the languages into a particular order; this is the order in which the languages will appear when listed together—in form select lists, for example.
Note
Our examples in this chapter are using English, Danish, and French. If you want to follow along with these languages, but do not know the translations in our examples, you can simply put the name of the intended language in place (e.g., if you are translating the Welcome post, you can type “DANISH Welcome” or “FRENCH Welcome”) so that you can easily distinguish which language is being displayed.
You can also choose to edit the language name, negotiation identifiers, and direction, as seen in Figure 8-12, by clicking the “edit” link. Normally, you won’t want to change these settings unless you have a very good reason, so we are going to leave all of our settings at their comfortable defaults.
Now we need to make a choice about how and when Drupal will use our new languages. To make it easy for users to see our site in different languages and allow them to pick as they like, we will also add a simple language switcher to the site.
As discussed earlier in Language switching, we have several options to choose from. Our client does not have separate domains for the languages, so they are just going to use Drupal’s path prefix. We also want to make sure that we honor the user’s preference, if she has set a preference in her account settings. We are going to use the URL and User detection methods, so that the site will first check the URL, and if that is not valid information, it will fall back to the user’s preference, if she’s selected one. If neither of those are applicable, then the site will fall back to using the default language, which in this instance is English.
Return to the Languages page by going to the administrative toolbar and clicking Configuration→Languages, then click the “Detection and Selection” tab (admin/config/regional/language/configure).
Check the boxes for URL and User and click “Save settings.”
The Locale module provides a block to switch languages, which can be configured just like any other block to have a different (or no) title, and have various display options set.
In the administrative toolbar, click Structure→Blocks (admin/structure/block) and find the “Language switcher” block in the list under the Disabled section.
Set the block to appear in the “First sidebar” region, drag it to the top of the block list for that region, and then click the “Save blocks” button.
You should now see a new block called Languages, which contains a list of each installed language on the site, as shown in Figure 8-13.
You may notice that even though you are using a translation that you have installed, there might still be some untranslated text peeking out here and there. This will become more likely as you add contributed modules. Almost no site will have absolutely 100% language coverage out of the box, so you will probably need to translate a few items yourself. Drupal has a built-in system to do this with the Locale module, but using it can be clunky and tedious. This is where the contributed “Localization client” module really shines. It makes quick text fixes easy and intuitive.
The “Localization client” module adds a translation editor right on the bottom of your screen that stays with you as you move through the site. You can minimize it when you don’t need it and then expand it when you do. Figure 8-14 shows the editor expanded on a page. It provides a nice, easy-to-use interface to see which strings on the page have been translated and, more importantly, which have not. It allows you to browse or search through the list; you can simply select the string you wish and add the translation right there on the screen.
There are some important caveats to keep in mind, however. The “Localization client” module is a great tool but it does depend on JavaScript and, at the time of this writing, it does not assist with translating strings that are added by the Internationalization module (which we’ll discuss later). Additionally, it can only translate text that can be seen by the person running “Localization client”; for example, if the text is visible only under certain conditions, it may not be translatable with the “Localization client” module.
Not everyone wants or needs to install yet another module, and due to the caveats we mentioned about “Localization client”, it is still a good idea to be familiar with how core translation works, so let’s start there.
Interface translation depends on the Locale module, which should already be enabled on your site once you have installed a translation.
In the administrative toolbar, click Configuration→“Translate interface” in the “Regional and language” section (admin/config/regional/translate) to get started.
You will be presented with a table of your languages and the percentage of strings that have been translated so far. Click on the Translate tab (admin/config/regional/translate/translate).
The “String contains” search box, pictured in Figure 8-15, allows you to search for a specific piece of text somewhere in Drupal’s interface and then translate it.
Enter the string
multilingual supportin the search box, leave the rest of the settings at their defaults, and click Filter.Warning
There are two caveats to successfully finding a string to translate. First, the search interface is case-sensitive. Searching for “User” will return different results than searching for “user.” Second, the page with a given string on it must have been visited after the Locale module was enabled, or Search will be unable to find any of its interface text.
On the search results page, pictured in Figure 8-15, you will see a list of all the places on the site where that string is seen. The translation status is in the Languages column, which lists the language codes. A strike through a language code means it is not translated yet. Here, searching returned several results, which are all translated.
Click the “edit” link next to one of the strings, which will bring you to the translation page, as shown in Figure 8-16. You will be presented with a text area for each language, where you can add or edit the text as appropriate. When you click the “Save translations” button, the strings will be updated.
As you can tell from the previous section, it is hard to see the strings that need to be translated on your site, remember them, go to the Translate interface, search for them, and only then actually be able to translate. It is a cumbersome, tedious process. Luckily, there’s an easier way: the “Localization client” module.
In the administrative toolbar, click Modules (admin/modules) and enable:
Multilingual package
Localization client
In the administrative toolbar, click People→Permissions (admin/people/permissions), configure the permissions shown in Table 8-1, and then click “Save permissions.”
One very important thing you need to understand is that the “Localization client” module will not work with text that is located in the administrative overlay. To make it work correctly in the administrative interface, we are going to disable the Overlay module temporarily as we work through our translations. When we are done, we can re-enable Overlay. So, head back to the administrative toolbar and click Modules (admin/modules). Disable the “Core: Overlay” module and click “Save configuration.”
Now you can go to the home page of your site, where the Languages block is displayed, and switch your site into a language other than English by clicking a language name. You will see a small blue bar appear at the bottom of your screen with a black Translate Text button on the right side (Figure 8-17).
Click the Translate Text box, and a translation area will open up at the bottom of your browser window, as shown in Figure 8-18. All of the highlighted green items listed under Page Text have already been translated. Ones in white still need work.
You can limit the list by searching in the text box at the bottom of it. In the administrative toolbar, click Modules (admin/modules) and type
Translateinto the search box (note the capital “T”). The list will update as you type, and it should bring up the string “Translate field properties,” which is provided by Internationalization’s “Field translation” module as its description. Unless someone has provided a translation file for the module in your language, the English should show up as white (untranslated) in the search results.When you click an item in the Page Text list, it will be placed in the Source box so that you know which text you are working with. If it already has a translation, that text will appear in the “Translation to language” box.
You can add or edit the translation as needed and click the “Save translation” button. For example, “Oversæt feltegenskaber” is the translation of this string into Danish. Figure 8-19 shows the “Localization client” screen with the English string selected and the Danish translation ready to be saved.
When finished, click the black X in the top bar of the translation area to close the client.
When you reload the page, you will see the changes you made, if any.
Once our translations are done, we can re-enable the Overlay module and click “Save configuration.” You can also switch the site back to English by going to the home page and selecting English from the Languages block.
When it comes to translating your site’s content in Drupal 7, we have two possibilities. There is the core “Content translation” module and the contributed “Entity translation” module. They have quite different approaches to translation. The major difference is that “Content translation” lets you create multiple versions of the same content in different languages and associates the translated versions together as a set. Each translation is an individual node, so for each piece of content on your site, you will have as many nodes as you have translations. For example, an English node with three other language translations (say, Danish, French, and Spanish) will be a set of four full nodes on your site. With “Entity translation,” you only have one node (an entity), and each field on the node will have multiple values, one for each translation.
Both systems have pros and cons, and you could mix and match both of them on your site for different content. Having multiple nodes can cause problems when you have associated metadata that you don’t want spread out over several nodes. For example, if you have an event node and you want people to sign up for the event, you don’t want people to sign up across four different nodes, depending on the language they read it in. You’d want one, central list of all the attendees for the event, regardless of language. On the other hand, having one node with just the fields translated would solve that problem, but what if you want to have separate content workflows for different languages? Gábor Hojtsy, who has worked on a lot of the Drupal core language system, has a very good presentation on the differences between the two systems on http://groups.drupal.org/node/165194.
At the time of this writing, “Entity translation” is only in an alpha version, and there are plans to make significant changes to improve it by updating the user interface and by providing more integration with core (with search in particular) and contributed modules. The ultimate goal is to get this work into Drupal 8. It is simply too early to use it for a real site since it is very much in flux. Once it settles down and there is a stable release in the future, though, “Entity translation” is very likely to become the standard way to provide content translation. Since we have to use what is available, we’ll stick with the tried-and-true core “Content translation” module here, but it is definitely worth keeping an eye on “Entity translation” down the road.
So, let’s look at the core method for identifying and creating multilingual content. The Locale module will give you the option to enable multilingual support for your content types. Enabling multilingual support will give you a drop-down select box, shown in Figure 8-20, to choose the language that each post is written in. All this will do is identify the language being used for that content.
When you use the “Content translation” module, you get an additional option under multilingual support: “Enabled, with translation.” Using this setting not only identifies the language for the post as written, but also allows you to associate other nodes as translated versions of the same content. For example, you may want to have an About page on the site that has the same content translated into French and Danish. With translations enabled, you would create the original About page and then, from that, create a brand-new node each for the French and Danish versions. Drupal will keep track of these three nodes and know that they are related, each one simply a version of the same page. On each page, there will be a link for the other translations at the bottom of the post, as indicated in Figure 8-21.
With our interface taken care of, now we can configure multilingual support for our content. That is, we need to be able to identify which language a given piece of content is written in and then create translations. So, we already have articles, and we need to add a knowledge base to the site as well. For both of these types of content, we’ll need to identify the language they are written in, as well as provide related, translated versions.
First, we will set up our content types with multilingual options so that we can assign a language to each piece of content:
In the administrative toolbar, click Modules (admin/modules) and enable the following modules:
Core
Book
Content translation
Then, in the administrative toolbar, click Structure→“Content types” (admin/structure/types) and click the “edit” link for the “Book page” type.
Scroll down the screen and click on the “Publishing options” tab. You will see several options for “Multilingual support.” Select the “Enabled, with translation” radio button, as seen in Figure 8-22, and click the “Save content type” button. This lets us identify the language for each piece of content, and in addition, lets us create translated versions of the content that will be linked together automatically.
Repeat for the Article content type.
Now we can edit our front page article and set the language for it. (If you are not using the installation profile that provides a front page article, go ahead and create one.) Go to the front page of the site, click the title for the article there, and then click the Edit tab. Scroll down to the Language setting and select English. Save the content.
We want all users to be able to translate content for us, so we need to make sure we set the permissions for everyone but anonymous users. Because all users are authenticated, we can do this by enabling the permission for all authenticated users. In the administrative toolbar, click People→Permissions (admin/people/permissions), configure the permissions shown in Table 8-2, and click “Save permissions.”
We now have a way to assign a language to content, and we’ve done this for our existing front page article. Now we need to look at creating translations and set up the Knowledge Base section of our site:
Make the Introduction to the Knowledge Base in English. From either the toolbar’s shortcuts bar, or the Navigation block, click “Add content”→“Book page,” fill in the fields as shown in Table 8-3, and click Save.
Table 8-3. “Book page” content
Field
Value
Title
Introduction
Body
This knowledge base is a place to organize useful information. Anyone with a Blue Peak Fanatics account can add to this book! You may create a new page by clicking the “Add child page” link at the bottom of any existing KB page or by going to Add content→Book page in your navigation block.
Language
English
Menu settings tab
Provide a menu link
checked
Menu link title
Knowledge Base
Book outline tab
Book
<create a new book>
After you save the content, you will see that there is a Translate tab next to the normal View, Edit, and Outline (for book content) tabs. Click the Translate tab, and you will be presented with a table listing all of your site’s enabled languages, which you can see in Figure 8-23.
Click “Add translation” for a language, and you will be presented with a screen containing the form values that were previously submitted. You may now edit the text for the Title and Body. Notice the language is already selected for you. Translate the text into the selected language, and remember to again create a menu item, give it a title, and choose “<create a new book>” in the “Book outline” tab as well, so that this translated introduction page will also be a top-level book entry for those viewing the site in this language.
When you click Save for this new translation page, you will see that there is now a link at the bottom that will take you to the other language’s version of the page. You can also see that our Languages block indicates which languages this page is available in. The translated pages have active links, but the untranslated language (French, in this case) is not an active link and has a strikethrough, as seen in Figure 8-24.
You should do the same for the Welcome post on the front page or any other content that was created prior to enabling content translation. Just edit the existing post to select the language and use the Translate tab to add versions for other languages, as we did previously.
Note
Keep in mind that the default language setting for all content is “Language neutral.” You must identify the content with a language in order to see the Translate tab and proceed with creating translations. If you do not set a language when initially creating the content or if you have enabled the “Content translation” module after already creating content, that content will be set to “Language neutral.”
When you create a translation for any content that is on the front page of the site (like the Welcome post in the profile), you will notice that each translation appears. The same thing is happening for our Knowledge Base menu items, as you can see in Figure 8-25. We’re going to address that issue in the next section.
So far we’ve got a nice start with getting our site translated, but everything is not quite smooth yet. We have translations for some of our content and menu items, but they all appear at the same time. There are multiple posts on the front page, and all the language menu items are shown regardless of which language we are viewing the site in. You will also see some stray text still in English. For example, under the “Create content” menu item, our content type names and descriptions are not translated, nor is the Home menu tab. To take our multilingual site further and really make it shine, we are going to turn to a package of modules called Internationalization (i18n). There is a central Internationalization module, which comes packaged with a handful of other modules designed to work together to extend core’s multilingual features.
One important thing that these modules do is help us get various
strings of text into core’s translation interface that are otherwise not
available. Drupal’s core interface tools can detect only strings that
are hardcoded directly into the code (using Drupal’s t() function)—that is to say, that are
code-generated. All of the user-generated strings are not accessible. It
is important to realize that these strings that are added by the Internationalization modules will
not be available to you through the “Localization
client” module’s “Translate Text” interface. To translate these, you
must use the core interface, covered earlier in Hands-On: Translating the Interface.
A second feature that many of these modules add is a way to select a language for an item, such as for menus, blocks, or taxonomy terms, like the one we saw in our “add content” forms earlier with the “Content translation” module. Being able to discretely identify the language being used for an item allows the Internationalization module to filter the display based on the languages we want to see, leading to less duplication and confusion.
The Internationalization package of modules provides a lot of tools; we will not need all of them for the Blue Peak Fanatics site. We will discuss what these tools are and then see some of them in action as we proceed with building our site.
One of the first things you probably noted after making your first piece of translated content was that all of the translations were showing on the front page, regardless of the language in which you were viewing the site. Internationalization’s “Multilingual select” module helps us get this under control. It adds a new tab called “Multilingual settings,” seen in Figure 8-26 , where you can determine if the site will filter the content based on language. You can enable it site-wide in the “Content to filter by language” section, but you can also exclude certain items from the Internationalization filtering. The best example of this is provided as a default setting by the module: Views. Since Views provides its own ways of filtering the content, you don’t necessarily need or want Internationalization to get involved. You can also disable the language filtering for certain pages on the site. The default setting excludes the administrative pages from language filtering. This makes all administrative pages display in the site default language.
The Strings module is required for most of the Internationalization modules. It doesn’t do anything on its own, but when used in conjunction with other Internationalization modules, it turns various pieces of text on the site into translatable strings that are added to the core translation interface.
A Drupal site can have many bits and pieces of text that are not associated with any particular node. These site-wide settings are stored in the database and referred to as variables. Some examples are the site name and slogan, found on the Site Information screen, or the registration email templates found under “User settings.” There is no simple way to get these particular kinds of text into the regular translatable string interface. The Internationalization “Variable translation” module, which is dependent on the Variable module, adds the ability to tell Drupal specifically that you wish to provide translations for these variables.
The Internationalization module also works with a number of core modules to aid with translations:
- Menu translation
The Multilingual Menu module adds any custom menu items you create to the translate interface string list. You can also specify which language a particular menu item is for, and its display will follow the rule you selected for content display. You should note that, independently of this module, you can create a menu item in a language for each node, which will also follow the display rules. So if you are only creating menu items based on nodes, you do not need to enable this module. If you wish to have menu items that don’t point to specific nodes, then this module will let you create the translations you need.
- Taxonomy translation
Multilingual taxonomy gives you a few options for keeping track of your taxonomy translations. When creating a new vocabulary, you can choose whether you want to localize the terms using the regular translate interface method, set up independent terms per language, or set one language for the entire vocabulary. When you choose to create terms per language, you will be able to select a language for each term. Once you have created the terms and assigned a language for each, you can then create associations between them. For example, the terms “cat” (assigned to English) and “le chat” (assigned to French) can be marked as equivalent terms.
- Block languages
The Multilingual Blocks module will let you pick a language for each block. Assigning a language to a block will determine when it is displayed according to the main content display settings. For custom blocks that you create, you can also decide whether you wish the block text to be translatable by adding the strings to the translation interface.
- Multilingual content
This module provides some extended settings for nodes to give you more control over the translations and workflow for content. For example, you can set a default language per content type, require certain languages, as well as use this to provide translations for the configuration text (e.g., the content type names).
- Field translation
While this may seem like it will allow you to translate individual field content, this is actually a module that lets you translate the text for a field’s settings, including things like the help text.
The “Contact translation” and Multilingual Forum modules simply allow for those two core modules to work well with Internationalization.
The “Path translation” module allows you to map together existing paths that are translations of each other. Most paths are linked for you through regular translation modules like “Content translation” and “Taxonomy translation.” This module will let you link arbitrary paths, such as when you are using the Panels or Views modules.
One last Internationalization module in the package is Translation Synchronization. This module will keep your taxonomy and node fields synchronized between several translations of a node. For instance, if you have a piece of content like a blog post that is in three languages and has a term selected, this module will make sure that the term changes on the other two nodes when you change it on one.
Now that we have these great tools available to us, let’s enable a few of them and start to really round out our site.
Translated content is all shown by default. The main Internationalization module will let you display only content that is relevant to the language currently in use:
In the administrative toolbar, click Modules (admin/modules) and enable the following modules:
Multilingual – Internationalization package
Internationalization
Multilingual select
Other package
Variable
In the administrative toolbar, click Configuration→Multilingual system, under the “Regional and language” section (admin/config/regional/i18n), where you will see the options for “Languages for content.” By default, it is set to “Enabled languages only,” which what we want, so we can leave it be.
Click the Selection tab (admin/config/regional/i18n/select). This is where we determine how we would like our translated content to appear. The default settings are good for us, so we can leave this alone as well. Close the Overlay screen and you will be returned to the site.
If you go to the front page of the site, you will see that we now only get one Welcome post and one Knowledge Base menu item. If you choose Dansk from the “Language switcher” block, you will see that the Danish “Velkommen” post appears, and the menu items change to the Danish versions.
Now the content we see is more streamlined, as shown in Figure 8-27. Let’s move on to translating other items in the site that are being stubborn, such as the site name, Blue Peak Fanatics.
Before we can translate the various site-wide variables, we need to let Drupal know which ones we want to make translatable. To do this, we’ll need to use the “Variable translation” module.
In the administrative toolbar, click Modules (admin/modules) and enable:
Multilingual-Internationalization package
Variable translation
Other package
Variable realm
Variable store
Before we can begin translation, we’ll need to identify which variables we would like to be made translatable. In the administrative toolbar, click Configuration→“Multilingual settings,” and click the Variables tab (admin/config/regional/i18n/variable). You will be presented with a list of variables that are available to be translated.
You can select as many variables here as you would like, but all we need for this task is to check the box for “Site name” and click the “Save configuration” button.
Now we can begin translating. In the administrative toolbar, click Configuration→“Site information” (admin/config/system/site-information). At the top of the page, you will see a box indicating that there are multilingual variables on the page, as well as providing language switcher links. As shown in Figure 8-28, each variable that is translatable will also have underneath it the text “This is a multilingual variable.”
Switch to another language by clicking a link under “Select language.”
Change the text in the “Site name” field, and click the “Save configuration” button. Notice that you are returned to the page with the language set back to the default language (in our case, English).
Note
The language selection links provided by the “Variable translation” module don’t change the language of the entire site or page. They only change the language for the fields that can be translated. The language you are currently looking at is indicated by that language’s link displaying as bold text. It is a subtle difference, so make sure you look closely to ensure you are working with the correct language.
After you have translated the languages you wish, return to the home page and select a non-English language. You will now see that the site name has changed to what we entered. If you switch back to English or another language, you will see that the site name changes with the language.
We’ve changed the site name variable, but we still have other stubborn text on the site that wasn’t listed on the “Variable translation” page to select. Our content types for the site are still using English for the content type name on the “Create content” page, and for field names when making new content.
In the administrative toolbar, click Modules (admin/modules) and enable:
Multilingual package
Field translation
Multilingual content
String translation
You should now see a message at the top of the module list that indicates a number of strings were refreshed.
In the administrative toolbar, click Configuration→“Translate interface” (admin/config/regional/translate), and you will see two new columns, “Fields” and “Node types” added to the Language table. It shows the number of new translatable strings that the Internationalization module has created for each of them. You can see the new column in Figure 8-29 and compare that to the table shown in Figure 8-3 earlier in the chapter. The percent translated should still be 0, because we haven’t translated any content types yet.
Click the Translate tab and search for “Book page” (note the capital “B”). You should see three results, just like Figure 8-30: two that are already translated from the “Built-in” interface group and another, not translated, in the “Node types” group.
Click the “edit” link for the “Node types” string. Go ahead and translate the word for your language(s), as shown in Figure 8-31.
After saving the new translation, if you switch to another language and go to “Add content,” you will see that the content type name for the book page is now displayed in that language. Click the link as if to create a new “Book page.” You will see that the Title and Body fields are still in English.
Note
It is important to remember that the Title “field” on a content type form is not technically a Drupal field. The Title is a hardcoded part of the content type itself. All other fields on the form, including the Body field, are real Drupal fields, attached to the content type. This distinction is very important when you’re dealing with translations.
Let’s switch back to English and go back to our translation administration. In the administrative toolbar, click Configuration→“Translate interface” (admin/config/regional/translate) and click the Translate tab.
Enter the word
Title. We also know that we are looking for this word in the context of node types right now, so select the “Node types” item under the “Limit search to:” section of the search form as shown in Figure 8-32. Then click Filter.We get three results for this, one for each of the content types we have on the site (Article, Basic page, and Book page). Click the “edit” link for the one that is listed with a Context of “type:book:title_label,” translate it, and save.
We can do the same thing for the Body field, but we will want to limit the search to “Fields” this time.
Switch back to another language, and go to “Add content” again. Select “Book page” and you will see that the Title and Body labels are now translated.
When using Drupal’s taxonomy system, we need to find a way to sync the terms that we create to keep the taxonomy selection limited to just the terms for a given language. We don’t want all of the different languages showing up at the same time when someone is looking at a vocabulary or individual terms on the site.
The Forum module creates a new content type (“Forum topic”) when it gets enabled, along with a Forums administration screen, found at Structure→Forums (admin/structure/forum). The Forum module’s containers and forums structure is built on Drupal’s core taxonomy, so it is also creating a new vocabulary on our site, titled Forums. You can modify the container and forum names either on the Forums administration screen or on the Taxonomy administration screen, found at Structure→Taxonomy (admin/structure/taxonomy).The forums on our client’s site need to display the threads that follow the same content selection rule as the rest of the content on the site. That is, we’ll only show the forum posts for the selected language. The site will have preset containers and forums, and then users may post to them using whichever language they choose.
Using the install profile, we have the default container, “General discussion,” as well as two forums, “Equipment” and “Travel advice.”
Note
If you have not used the install profile, go ahead and enable the core Forum module and add some forums under the “General discussion” container by going to the administrative toolbar and clicking Structure→Forums (admin/structure/forum).
Let’s turn on multilingual options for the forums:
First we need to set up the “Forum topic” content type so it can be used for multiple languages. Unlike the “Book page” and “Article” content types, these do not need to be translatable. We just want a user to identify the language of the post so it appears in the proper language forum. In the administrative toolbar, click Structure→“Content types” (admin/structure/types), and then click the “edit” link for the “Forum topic” content type.
Under the “Publishing options” tab, select the Enabled radio button for “Multilingual support.” (Note, we are not using “Enabled, with translation.”) Click “Save content type.”
Now let’s see about making the forum container and forum names translatable. In the administrative toolbar, click Modules (admin/modules) and enable:
Multilingual-Internationalization package
Multilingual Forum
Taxonomy translation
Translation sets
In the administrative toolbar, click Structure→Taxonomy (admin/structure/taxonomy) and click the “edit vocabulary” link for Forums. You will see in Figure 8-33 that we now have a “Multilingual options” section on the page.
Select the radio button for Localize and then click the “Save and translate” button to save your changes and move directly to translation. You will see a table listing the languages available for translation, along with the translation status, as shown in Figure 8-34.
Click the “translate” link for a language, enter the translated text for Forums, and save your changes.
When you are done with these translations, click the List tab for the Forums vocabulary (admin/structure/taxonomy/forums). We still need to translate the containers and forums now, which are simply nested terms in our Forums vocabulary.
Note
While you can control the default language and ordering of containers and forums using the Forums administration page—found at Structure→Forums (admin/structure/forum)—you must complete all of the translations for the forums in the Taxonomy administration pages.
Click on the “edit” link for a term, then click the Translate tab. Here you can change the name and description, just as you did for the vocabulary. Do this for each of the Forum terms. After you edit a term, you will notice that you don’t have an easy way to get back to the list of all of the terms. You can either use your back button on your browser, or go to the administrative toolbar and click Structure→Taxonomy, then “list terms” for the Forums vocabulary (admin/structure/taxonomy/forums).
Last, we want to add a Forums menu item into our Main menu so everyone can easily find it. The Forum module has already created a menu item for us, but it is located in the Navigation menu. (Remember that modules will add new menu items to the Navigation menu by default.) So we just need to move it from Navigation into the Main menu. In the administrative toolbar, click on Structure→Menus (admin/structure/menu), then click the “list links” link for the Navigation menu. Find the Forums menu item and click the “edit” link. Select “<Main menu>” from the “Parent link” select list and save your changes. You can drag it into a better location if you’d like.
When you close the administrative overlay, you will see a Forums menu item in the Main menu. If you change the language using the language switcher, you will see the menu item change names with the language selected. When you go to the Forums page, the forum names are also translated. Finally, if you click the link to “Add a new Forum topic” from within the forums, you will see that the node creation form includes a select list to pick the language for the post.
The last little thing we need to do to clean up our site is to get our Home tab in the Main menu translated as well:
In the administrative toolbar, click Modules (admin/modules) and enable:
Multilingual package
Block languages
Menu translation
Now, in the administrative toolbar go to Structure→Menus (admin/structure/menu), and click the “edit menu” link for the Main menu. There is a new “Multilingual options” section here. Select “Translate and Localize.” Menu items with language will allow translations. Menu items without language will be localized.” Then save your changes.
You will be returned to the list of items in the Main menu. Click the “edit” link for the Home menu item. Scroll down, select English for the language, and save your changes.
Now when you click the “edit” link again for the Home menu item, you will see there is a Translate tab. Click on that tab, enter in your translations, and save them.
When you are done, go back to the Main menu list of menu items; in the administrative toolbar, go to Structure→Menus (admin/structure/menu); and click the “list links” link for the Main menu. Drag and drop the menu items so all of them are in the correct order, especially your translated items.
Return to the home page on the site and switch to another language. You will have a fully translated menu now.
We’ve covered quite a bit of ground for setting up a site with multiple languages. There are a lot of tools available, and therefore there is a lot of flexibility when it comes to handling languages. We have delivered a site to our clients that has the community features they need and allows their users to both participate and manage the site in the language of their choice. They can easily add new languages to the mix in the future, and everyone can help with translating their knowledge base. Here are some additional modules that can add some nice touches to your site:
- Language icons
This module will add a default set of flag icons to the language switching links on the site (in the “Language switcher” block and language links on the content). You can replace the included icons with ones of your choosing.
- Language switcher dropdown
This gives you language switcher that provides a drop-down select list, instead of a list of links. This integrates with the Language Icons module as well.
- Transliteration
This important module will transliterate Unicode characters into ASCII. This is very important to avoid creating URLs and filename paths that are unreadable in some circumstances due to non-ASCII characters.
- Translation overview
This module creates a page with a table that tracks the translation status of all the content on your site. It supplies basic information like the title and a link to the content, content type, and creation date. Then, for each piece of content, it uses a legend so you can see the translation status (original language, current translation, out-of-date translation, or untranslated) at a glance.
- Translation table
This module provides a nice table interface to make it easier to change the text for menus, taxonomy, and other strings.
We built a nice, simple, easy-to-use site for our clients that gave them the tools they needed for discussions and a knowledge base. We set up a forum that displays only posts that are in the user’s language and a knowledge base book where all of the site members can create translations for the pages. The major need for this community was being able to use multiple languages and easily extend those languages in the future. Using Drupal’s core internationalization features with a handful of contributed modules, we have given them a very flexible multilingual solution.
For more information and discussion about internationalization in Drupal, see the Internationalization group. To get more information about core Drupal translations and how you can help, check out the Translations group. If you’d like to help the project by providing your own translations for Drupal core or contributed modules, the Drupal.org translator’s guide has all the information you need.
Here are the modules that we referenced in this chapter:
Book: Part of the Drupal core
Content Translation: Part of the Drupal core
Forum: Part of the Drupal core
Locale: Part of the Drupal core
These are some other resources that we referenced and community resources for learning more about the new concepts introduced in this chapter: