Every organization 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 localization 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
  • Search
  • Front-end performance
  • Ease of use for editors
  • Content reuse
  • Keeping and enriching base content
  • And don’t forget code internationalization and localization (i18n)

A natural first step towards solving these localization challenges should be common to every proposed solution—namely that of structured content. Localization 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 localization.

For our purposes, we use the concepts of “translation” and “localization” in accordance with Bear Group’s definitions:

  • Translation: word-for-word translation of your content
  • Localization: adjusting meaning to fit a different sociolinguistic understanding

We must also not forget that localization doesn’t necessarily mean translation to different languages. Localization 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, localized common content, and layering.

Approach 1: Independent projects

Localisation- Separate

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 organization, 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 organizations 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 synchronization
  • Maintenance

See also: How Enonic's community can help your projects »

Approach 2: Using translations

Localisation - Common

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, localized 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 customization
  • Changing structure in different language sections
  • Fallback system
  • Search: when content doesn’t exist in a given language, what to search?


Approach 3: Layering

Content Layer Grandchildren Non-Multi inheritance

Layering utilizes 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 localize 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, localized 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: Localize your content with Enonic »

Don’t forget a domain strategy

Regardless of which localization 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 optimize your organic traffic.

How to choose an experience platform that fits your architecture and skills

Related blog posts

Get some more insights 🤓

Get started with Enonic! 🚀