Multilingual sites with Drupal

Fighting spam is an ongoing arms race. There will always be nefarious attempts to post unwanted content onto websites, that's just the nature of the global internet nowadays, but can we keep ahead of it? Some techniques are complex, maybe using AI / natural language processing, but there are also quite simple opportunities to reject spam. We had a lot of contact requests come into our site that used the Cyrillic script - which is...

I recently released a new contributed module to aid translation on Drupal 7 sites: Entity Translation: Separated Shared Elements Form (ETSSEF). Yes, it has a convoluted name! It finally resolves a suggestion from years ago in an Entity Translation project issue, to allow editing untranslatable fields separately to translatable ones. One of our clients has a multilingual product database site with a few hundred fields on their content, so anything like this that could reduce...

We've been busy recently, but that doesn't stop us at ComputerMinds contributing back to the Drupal community! For our latest multilingual website, we needed an XML sitemap with alternate links and hreflang attributes. This site uses separate domains for each language - for example, www.example.se (??) and www.example.no (??). Search engines need these alternate links to help them understand how to match up each translation of a page, which are distributed across these different domains...

Do you want to reach more markets and people? Do you want to tailor your content for clients from a range of locations around the world, without having to manage every single translation? Then the Language Hierarchy project could be for you! I wrote a while ago about how this module gives editors more power and flexibility without the extra effort that can come with each translation added to a site. Now Drupal 8 sites...

A super quick blast from the past today; a Drupal 7 based article! I had some work recently to create a new "setting" variable for one our Drupal 7 multilingual sites, which meant creating multilingual versions of those variables. I soon found out that there is very much a correct way - or order - to achieve this as I got this one very wrong (I had to re-instate my DB!). So here I am...

Several of our recent projects have involved setting up languages that feel like 'child' languages of other languages, for a variety of reasons. Sometimes it's for marketing, so that content can be overridden for markets using a specific currency, other times it's to target a specific audience. Our classic examples are 'Euro English' and 'British English' - in either case, these are special cases of regular English. A more traditional example would be Canadian French - where most content would be the same as French, but some pages would want different spellings or customisations. We came across Amazee Labs' work on language fallback which inspired us to work on the Language Hierarchy project.

To complete my series on multilingual Drupal, here are some mini-lessons I've learnt. Some of them are are to improve the experience for administrators & translators, others cover obscure corners of code. The first few don't require any knowledge of code, but the later ones will be much more technical.

Content (node-level) translation or entity (field-level) translation? It seems an obvious question to ask, but what are you translating? The tools exist to translate just about anything in Drupal 7*, but in many different ways, so you need to know exactly what you're translating. Language is 'a first-class citizen', in the sense that any piece of text is inherently written by someone on some language, which Drupal 7 is built to recognise. Sometimes you want to translate each & every individual piece of text (e.g. at the sentence or paragraph level). Other times you want to translate a whole page or section that is made up of multiple pieces of text.

When you are going to have multiple language set up on your Drupal site, it's important to set the default language appropriately before creating content. Once that is set, content will normally be set to be in that language, and any translations made on the site will be assumed to be from the default language as the source. So changing it is not a good idea, as there's no way to differentiate between translations made before and after the switch in Drupal 6 or 7! (This has been resolved in Drupal 8.) So, once you've thought first about what is necessary for your multilingual site, the next step is to pick the right default language, ideally before setting up anything else, as everything is 'in' a language in some way. It's usually an obvious choice, but did you know that the Drupal software itself and associated modules (i.e. the codebase, referred to as the ' interface') is all written in U.S. English (as per the coding standards)?

Architecture has to be carefully thought through before implemented, or it could all come crashing down at an unexpected moment. You may not realise it, but language is a piece of architecture in all websites. Site builders will be used to thinking about how best to model content, usually in terms of content types, fields and vocabularies on Drupal sites. Every piece of text is modelled somehow - and every piece of text is written in some language. As soon as it matters which language that is - so that translations can be associated with each other and shown beside or instead of one another - that content model needs to incorporate language.