With the long-overdue passing of Joomla, Drupal has become the ascendant open-source CMS and is beloved by companies and governments alike. Here at Andovar we get called upon to localize all types of websites, and all flavors of CMS, but they’re similar enough that we’ll use Drupal as a typical case study.
Localization within CMS Past vs. Localization through Modern CMS
Not so long ago website localization with fairly straightforward, with content sitting in static HTML files or perhaps a database that was amicable to a CSV export.
However, CMS systems have come a long way in recent years, and the content served up to a website visitor no longer lives in a simple cells-and-columns relational database but rather lives in complex structures along with a host of metadata describing what it is, where it’s supposed to go and what to do with it.
Preparing Drupal-based Content for Localization
Drupal’s internal structure is all built on Nodes, which start out as simple objects and get built into more complex Content Types, which may describe a web page, blog post, product or whatever. These get collected together and put under menus to describe the site.
So the challenge for the localization company is to get this content out of Drupal in a way that makes sense to your Computer-Aided Translation (CAT) Tool. There are a couple of options for either exporting specific nodes or exporting the entire site, most of which end up as some flavor of XML.
Localizing your Content
XML is all well and good, you can import the XML into your CAT tool, get rid of all the metadata garbage and translate the content. The next challenge is to get the translated content back into Drupal, truly a toothpaste-back-into-the-tube exercise.
Obviously all this has been thought of before and Drupal sports excellent multilingual capabilities. You’ll probably have already set up your instance to be multilingual or you may have installed it that way. Drupal has been translated into 80 languages so you don’t have to worry about localizing the interface and everything is set up to serve your content in any language you like, it’s just a matter of getting it translated.
Drupal handles localization like a lot of open-source CMSs. Having grown from a community of enthusiastic users donating their own time and expertise, the obvious solution is to let users contribute their own translations. So in Drupal you can go to any node and add a translation in your chosen language.
This is great for a community of users or a big enterprise with in-house staff, but not so good for a firm that wants to outsource its Drupal localization requirement. By using the basic node-by-node translation offered out-of-the-box by Drupal, your professional translators have to come in, learn the system and translate each item, one by one, without the aid of CAT tools. You probably don’t want a bunch of strangers bumbling around your website either.
Putting the Toothpaste Back in the Tube: Reintegrating Translated Content into Drupal
So we’re back to exporting content and importing localized content. Luckily, there are tools to do this in a way friendly to LSPs. We recommend Translation Management Tools, which gives a familiar interface to select content to assign for translation. It tracks translation assignments but the real value is that it exports content as XLIFF files and accepts the same files back, meaning that the translation work gets done outside Drupal, but is exported and imported in a rational way.
This means that your localization service provider should be able to extract translatable content from source code, and revert the translated versions back in using CAT tools that also interface with translator workbench environments where the real translating work gets done when you’re working with a professional localization house.
There’s another module called XLIFF Tools which does exports, but it doesn’t seem to get updated very often and sometimes doesn’t work.
Each project is different, but when planning a Drupal localization consider the following:
- Is my content finalized?
- What format does my LSP need the content in?
- How am I going to get translated content back into Drupal?
- How am I going to cope with content changes in the future?
Of course there is plenty more to talk about, and a lot more technical detail to discuss, but this post should give a good idea of what to expect when localizing your Drupal site.
Need more information or advice? Please feel free to contact us for a free consultation. We have a full scale Language Technology Advisory Service and can empower your localization practice knowledge of technology and workflows that suit your business.
Find out more about website translation strategy in our Ultimate Guide to Website Translation.
