Language lessons: Think first!

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. Before diving in to configure languages and set up translations, you have to think how you want to represent and display translations. You may think that your expectations might match a 'standard', even trivial, way of doing translations, or follow a simple workflow, but _every_ organisation, individual or team has their own way of doing things. Your website should match the way you do things - not restrict or force you to do something else!

"Je pense, donc je suis"

What makes your content what it is? How do you produce content? Who will be managing the content? What about things that aren't strictly content, like the multitude of settings that shapes how your users interact with you? The answers to all these questions shape what your website is, and the idea of who or what it represents in your readers' minds.

• Will your website just show content in different languages alongside each other? In which case you could just use taxonomy terms to 'tag' each post, so users could just manually filter which posts they would like to see. This would be a very simple approach, but would certainly suit many use cases.
• Do you want to have content translated into multiple languages on your site (for example, a brochure-style website, where all the content is the same, but available in different languages), or is each language going to mostly have 'independent' content? You could always make simple links between translations if necessary if most of your content is independent usually.
• Is all your content produced by one source, such as a head office, that then sends the content out for translation - or is content in each language produced by multiple sources, which is then sent for central approval?
• Do you need the 'interface' of your website (e.g. links & text provided by Drupal itself or modules) to be in different languages?
• Will you be using different domains, subdomains, URL prefixes, or other methods to allow users to switch between different language versions of your site, with the entirety of each 'version' in a single language?
• Does your site need to share content/configuration between different language versions? If not, you could just set up each language version as a separate site installation (site), perhaps using Drupal's multisite capabilities to share some parts (e.g. modules), or just installed completely separately. This would mean each site only needs to be in one language.

All of these questions should affect the approach you take to implementing languages and translation in Drupal. Think carefully first whether you really need to set up Drupal's 'full' multilingual capabilities, _according to what you actually need_. Language can be a whole extra layer of complexity, so avoid over-engineering. Do not just follow the multilingual guides without thinking first!

Architecture image from flickr by Ken Ratcliff