Our top categories:

How to structure CMS content for international sites

This blog post by Abhay Kumar from Priocept gives advice on how to structure CMS content for global sites, including multi-tree vs. single-tree approaches.

From IT to content managers

Managing international content within a global website is one of the biggest challenges faced by many digital teams who are responsible for marketing their products and services worldwide. Software in the form of content management systems (CMS) has transferred control of content distribution from IT departments, associated with structured delivery cycles and rigid change control, to web content managers who work in a fast-paced environment and are driven by the urgency to merchandise or otherwise present relevant and impactful content at just the right time.

This transfer of control has enabled marketing teams to deliver targeted and timely content that ultimately creates a more engaging digital experience for audiences. But the trade-off is that website content tends to become less structured and difficult to manage over time.

In Priocept’s experience, one of the biggest mistakes in CMS implementation concerns the arrangement of content within international (multi-lingual, multi-cultural and multi-geography) websites. The key challenge is to arrange your content in such a way that it will allow flexibility across international sites, whilst avoiding duplication. Duplicating content will lead to duplication of content entry effort, which can have a significant impact on operating costs, combined with unnecessary inconsistencies between equivalent content.

With this is mind, we will explain some approaches for arranging content within an international website.

Multi-tree approach

The structure of content within an international website is often a reflection of the hierarchical and geographical structure of the organization itself, where content editors’ natural tendency is to create separate sites for each country which are then managed by their respective local content teams. This is the multi-tree approach.

For local content editors, this approach makes sense and gives the most flexibility as it allows them to create an entirely tailored experience for their market. But, for global marketing teams, responsible for overseeing the holistic digital content strategy, this approach can pose challenges to achieving unified messaging across the digital estate.

A further disadvantage of a multi-tree hierarchy is that it promotes replication and duplication of content across sites. A small change to a common piece of content will require replication into multiple local sites. This presents challenges for creating, testing, and managing content.

This approach is recommended for sites where the content is significantly different in structure between local, country-specific sites. If your content is generally uniform across sites, with perhaps some minor differences in certain areas, then this solution is not recommended as it will be unnecessarily difficult to manage.

Single-tree approach

The alternative approach is to have a single content tree. In an idealistic implementation, this single hierarchy represents a common set of content that is shared across all local (country-specific) sites, with the only differences being in language variations.

This is the cleanest approach when viewed from a content architecture perspective as it conforms to software engineering best practices, maintaining a “single source of truth” and avoiding duplication of content (which is essentially a form of data) and promoting data or content reuse through inheritance. It is also the most efficient approach as it opens up the possibility of managing all your content with one co-located team, rather than globally distributed teams.

Although this is a clean approach, it quickly falls short if local teams, who are naturally closer to the intricacies of the local markets they manage, need to make minor adjustments to reflect local differences. In a single-tree approach, local managers are simply not able to localize content effectively without resorting to workarounds, otherwise known as “content hacks”, which are very difficult to track and manage.

The single-tree approach is recommended if your content is mostly the same across local sites. Localizing the content structure will be harder to achieve than with a multi-tree approach, but the benefits of having a single, centrally managed set of content will far outweigh this.

Multi-tree with shared content

A compromise to these two conflicting approaches is to manage a central “abstract” site that contains content for global dissemination. This is a shared content repository, which in itself appears to be a stand-alone site, but need not actually be published to the live site. Instead, it is used to create linked copies of shared content in local sites. This abstract site is analogous to an abstract class in object-orientated software design.

Priocept works with a number of enterprise content management systems that provide functionality to create linked content items, where a parent or master content node is used to update multiple child nodes. Most recently we have been working with Magnolia, a Java-based, open-source CMS. Magnolia has several approaches for developing shared content, including the LiveCopy feature.

Magnolia LiveCopy

The Magnolia LiveCopy module allows content authors to generate copies of pages that are linked to the original source. This functionality allows content editors to maintain global (or shared) content in a central location where it can be updated once and disseminated to many local sites.

Figure 2: Magnolia LiveCopy - A linked copy of the travel site has been created.

Complete flexibility

Content is referenced within the properties of each page, which means that pages can be moved around, both in the source and in the linked page and the content link will remain intact. This approach also gives content editors the flexibility to add pages or sections underneath linked pages as illustrated below.

Selective content inheritance

In some cases, the content of the original source (or parent) page, created at a global level, has a small section that doesn’t quite work at the local level. In this scenario, it would be an unnecessary overhead to delink the entire page and have to manage all the content in this page locally. Instead, it would be much more efficient to be able to override the relevant section within the page, avoiding issues when the surrounding content needs to be changed in the future.

Magnolia’s LiveCopy module caters for this by allowing content authors to override components of a page to create a local version with certain properties overridden at the local level. For example, if a different title on the homepage of a French site is required from that of the Belgian site, the page title component can be edited in the local page and will override the parent page content, whilst the rest of the page matches the parent page and remains linked to receive any updates made.

Summary

Planning the structure of content for your international website is a critical consideration that needs to be right from the outset. The cost of reorganizing content structure once it has been embedded in a web team’s daily routine can be an unnecessary burden on marketing budgets. It is worth approaching the content architecture with the same rigor applied to software architecture, to design the most efficient approach ahead of implementation. Rather than allowing the content structure to be dictated by isolated local teams, a “content architect” needs to design the most appropriate solution to meet an organization’s particular needs, with consideration given to efficiency, scalability, and the robustness of the content editing process.

Comments

Your name:

Your comment:

{{item.userId}}{{item.timestamp | timestampToDate}}

About the author Abhay Kumar

Abhay Kumar is Head of Project Delivery at Priocept and has over 18 years’ experience of enterprise web application delivery. He is responsible for ensuring the effective delivery of all Priocept projects, including Magnolia implementations. He draws on his technical background to design and develop effective Magnolia solutions.