Localisation: 3 approaches to managing multilingual websites
How do you best localise content across different markets, languages, and teams?
Every organisation with a presence in different markets and regions has most likely encountered the following problem: How do you best manage content in regard to languages and local adaptations across multiple websites and apps?
While every CMS can produce and distribute content, you are at a crossroads the moment you need to expand upon the basic functionality. Challenges with localisation include:
- Multiple languages or content considerations across different regions and markets
- Different structures and URLs across various sites
- Different editors and access control across regions
- Different schedules for e.g. product releases across regions
- Front-end performance
- Ease of use for editors
- Content reuse
- Keeping and enriching base content
- And don’t forget code internationalisation and localisation (i18n)
A natural first step towards solving these localisation challenges should be common to every proposed solution—namely that of structured content. Localisation often entails reuse of content in different contexts, and structured content is the principle that enables reuse.
In short, this means that your CMS should support content types, where all content items of a specific type are structured in the same way—and therefore can be treated the same way in different scenarios. For instance, the same fields from a given content type—like a title, preamble, product info, or image—can be reused across different channels, like websites, apps, digital signage, wearables, and IoT.
It is content reuse like this that in turn will enable especially the more advanced approaches to localisation.
For our purposes, we use the concepts of “translation” and “localisation” in accordance with Bear Group’s definitions:
- Translation: word-for-word translation of your content
- Localisation: adjusting meaning to fit a different sociolinguistic understanding
We must also not forget that localisation doesn’t necessarily mean translation to different languages. Localisation can for instance mean enriching a product database that includes basic product information to different markets by adding marketing texts, and box texts, etc.
There are at least three main approaches to regional and multilingual websites: separate structures, localised common content, and layering.
Approach 1: Independent projects
This approach entails completely separate teams and even separate tools (even different CMSs!), where respective content teams and solutions work independently of each other in different regions. A strictly separated approach such as this enables full flexibility for your organisation, but it’s important to remember that content and structure is disconnected from others.
Each project thus has to be managed separately, with manual labour required to update, copy, and connect content between the different projects. Such an approach can be applicable to multinational organisations with very different content and structures between its local subsidiaries or member firms.
- Run freely
- Use preferred CMS, team, technology
- No need to relate to outside factors
- Can be too disconnected from central brand and unified message
- Missing synergies and reuse possibilities
- Difficult to effectuate and follow up (from a central perspective)
- Keeping content in synchronisation
Approach 2: Using translations
This second approach relates to using a single content and simply translating or recreating it in another language. In this option, both team and tools are placed in the same system, enabling close collaboration and synergies. If you have a website and want it available in several languages, localised common content can be a viable solution.
The most common way to solve multilingual requirements in this approach is to keep separate fields for different languages—e.g. one set of fields for English, a corresponding set of fields for French, and so on.
- Fast way to see translations and statuses
- Encourages content reuse
- Only translating: no intuitive method to select content for different markets
- Will quickly add to content noise and can cause editorial headaches
- Access rights management: what is published when? How to schedule independently?
- Separating content heading to different markets
- URL customisation
- Changing structure in different language sections
- Fallback system
- Search: when content doesn’t exist in a given language, what to search?
Approach 3: Layering
Layering utilises a blueprint and inheritance model to efficiently distribute and reuse content in different contexts. With this approach, teams work in separate layers, while content produced in one layer is inherited to all its child layers.
Each layer has separate access control, publishing, and default language, and content editors can localise per layer. Layering is thus not only fit for translations, but also data enrichment mentioned earlier, where you can enrich base data in different markets with separate layers.
- Intuitive and neat overview for editors
- Control content per market, minimal noise across teams
- Superb reuse possibilities
- Goes beyond translation, relates to data level
- Individual scheduling and market specific content
- Make most use of a distributed team with different people
- If a very small team must handle multiple layers, localised common content can be more appropriate
- If you have no need for different structures, layering can be slightly overhead
- Usability depends on specific tool
- May be more elements to keep tabs on
Read more: Localise your content with Enonic »
Don’t forget a domain strategy
Regardless of which localisation approach you choose, you must have a clear domain strategy. This means you must decide whether to choose different top level domains, subdomains, or URL parameters like .com/en and .com/fr.
Make sure that your chosen approach is supported by your current or future content platform, and also that it is SEO friendly to optimise your organic traffic.