Mastering Drupal Multilingual: Part 1 of 3
The web is constantly growing, evolving and—thankfully—growing more accessible and inclusive.
It is becoming expected that a user can interact with a website solely via keyboard or have the option to browse in their native language. There are many ways to serve the needs of non-native-language users, but one of the more robust is Drupal Multilingual.
Unlike 3rd party translation plugins like Google Translate or browser translation tools, Drupal's suite of core Multilingual tools allows you to write accurate and accessible translated content in the same manner as you write in your default language content. With no limit on the number languages, settings for right-to-left content, and the ability to translate any and all of your content, Drupal 8 can create a true multi-language experience like never before.
There is, however, a bit of planning and work involved.
Hopefully, this blog series will help smooth the path to truly inclusive content by highlighting some project management, design, site building, and development gotchas, as well as providing some tips and tricks to make the multilingual experience better for everyone. Part one will help you decide if you need multilingual as well as provide some tips on how to plan and budget for it.
Before you get too far into planning, the first question to ask is: "Do you really need multilingual?" Make sure that the project has a large enough timeline and budget that can support a multilingual build, because it will take significant resources. And make sure there will be enough translated content available to make it a good experience for users.
It is possible a 3rd-party service like Google Translate will be good enough for a smaller site without a large base of foreign language speakers. If your translations are limited to just a few pieces of content scattered around the site, it might be better to add that content as a few PDFs or pages that are simply written in another language, and don't require a full multilingual build.
Once the decision is made to build a multilingual site, it is time to start planning. Since multilingual impacts so many areas–project management, design, development, and content creation—the sooner you start planning, the better.
Some questions to ask:
- What languages are going to be used?
- Do you need to design for any right-to-left languages?
- Is the entire site going to be translated, or just certain sections or content types?
- Where are the translations coming from? Will they be provided by a service, by the client?
Right-to-left languages may provide an obvious design and layout challenge, but also remember that many languages use more words or much longer words than English. Leave some extra white space in the design of translated elements to account for this.
It will also be beneficial for site builders, developers and project managers to team up early to define any non-content translations needed. Non-content translations include things like Views filters, field labels, and text set in Twig templates or modules that cannot be accessed by site editors. These translations will have to be provided by the client and then added by developers.
Developing a spreadsheet or list of non-content translations, and providing that to the client or translation service early in the project, will allow site builders and developers to add translations to the site as they become available. Try to make sure, however, that these translations are finalized before adding them because each change to base language configuration or interface text is compounded on a multilingual site. The amount of work for each change is multiplied by the number of languages that change needs to be translated into.
The impact that multilingual has on a project's timeline and budget can be very difficult to anticipate. Factors like development resources, design complexity, the number of entities that need to be translated and the number of languages all come into play.
Here's a fun equation we came up to illustrate budgeting for a multilingual site. It's not completely scientific and proven, but we've found an increase of roughly 1/3 for timeline and budget is not a bad place to start. Due to its large impact on project scope, in some cases, it may be better to plan for multilingual integration as a later phase or a separate project.
Now that you've learned how to plan and budget for multilingual, part two of this series will provide an in-depth look at how to actually build a Drupal 8 multilingual site. We will cover the modules needed, adding languages, and the different types of translations and how to do them.
Join the Discussion +