International corporate sites - Episerver Multiple Languages in action

For Niteco, a software development firm that has a strong track record in building complex, multi-lingual sites, Episerver continues to be the go-to technology for multinationals. Big continues to be better as far as corporate execs and investors are concerned, but there’s a clear need to satisfy consumers’ preference for localized content.

That’s why Niteco is continually approached to build sites that can maintain a company’s global brand reputation - branding guidelines and content included - while still appearing to be locally influenced. Take for example, our client Bisnode which operates in 16 different European countries. In order to resonate equally and professionally as ‘thought leaders’ it was essential to Bisnode’s company strategy that local sites featured content in the relevant dialects.

 How did we do this?

Thanks to Episerver, Bisnode could create their corporate content in the group content hub, which can be accessed by local editors for translation into their local language. 

Below, Hiep To, one of Niteco’s Swedish-based Project Manager reveals how developers can structure the pages, blocks and forms:

In Episerver, the pages are structured in the shape of a tree. To build up a page, you can create content blocks and use in pages. The blocks will be structured in Episerver’s asset tree folder as well. For each language, Episerver supports the ability to translate pages to different languages.

Assess the solutions - to solve the multiple languages scenario, you have two options.

Option 1:

 All local sites use the same language with the option of mapping each language site to a different home page root

 -  Pros:

• Easy to copy and clone a new page
• Easy to create and maintain different content structures
• Setup the access rights which are separated by tree nodes

 -   Cons:

• Each tree node for the main site is separated by other local sites.
• You may face a challenge when using the translation flow to translate the master language to other languages
• The node for each tree will be duplicated so you will have a very long tree structure in the end

 Option 2:

Local sites use a different language with the same root

 -  Pros:

• Can set up a translation process to translate the master content to different languages
• Can setup the access right by languages
• Can develop a clear page tree structure that can be managed centrally.

- Cons:

• This option is more complex with copy, paste or move action.

The option we prefer is Option 2: Different languages using the same root for each language.

Why?

Because it’s the translation process that benefit editors the most. In addition, we don’t want to have a complex page tree with thousands of parent nodes.

But before anything is built, there are some questions that need answering, such as:

1. How do we limit the access rights for each country? What happens if an editor in one country moves the blocks and content around without any other editor from any other country noticing?

2. How will you bring the content from one language to other languages in a convenient and easy way?

3. Will the company’s editors create all content or will translation agencies, for example, also be required to populate pages?

4. What will happen if one editor deletes the pages so that the whole page node is moved to trash?

As a developer, the other essentials we need to think through, include:

• How we will structure the access rights for Pages, Blocks and Forms?

• What is the translation workflow from Master languages to different languages?

• What actions could be done on Pages?

• What level of flexibility does the company want to give to local editors?

 How to set the access right for Pages, Blocks and Forms 

• For pages: All the web editors will have access to the back-end link, but only the web editors working on the English language site will have access to edit English pages, and editors for the Swedish language site will have access to edit Swedish pages.

• For blocks: Set up a folder for each language or country:

• English: only English editors have the edit access - English WebEditors group

• Germany: only German editors have the edit access - German WebEditors group

• Poland: only Polish editors have the edit access - Polish WebEditors group.

            … and so on and so forth.

• And the same structure with the Forms; each country will have their own folders

• Editing Rights for each language: only the editors with access to the local group have the chance to translate the content.

 Our Recommended Translation Workflow

• The content will be created in Master language first (in this case we choose English)

• Language Add-ons can be used to help translate the content into different languages

• The blocks on pages can be translated to different languages if needed.

 Actions on Page Tree

• Because Episerver allows the editors to move or copy the page once they have the edit access, it could create problems if multiple editors from multiple countries try to duplicate the content and move it around

• But rules could be set up. For example, the Editors in the Master Language could move or copy the page, while editors working with other languages can be given access for translation purposes only

• If local editors have content that they create locally, they can create a page in their local language.

By adopting this approach, we’ve observed improved usability for editors. Certainly, you’ll find that there may be small things that need customizing in order to achieve a good workflow.  Episerver also supports content approval workflows that can be set up differently for each language. While these were not available when Niteco started to implement the solution for our client, it’s something that we recommend developers look into when starting or upgrading to the latest Episerver version.

To find out more about building complex multi-lingual sites, send me an email.