Skip to content

Set up and Management of Multilingual Websites in Sitecore

Globalization Partners International (GPI) provides comprehensive document, software and website translation services to help companies communicate and conduct business in any language and in any locale.

Web Content Management Systems (WCMS) provide a platform used by both individuals and organizations to power their online web identities. WCMS allow website authors to store, edit, share and publish content in multiple formats (e.g. document types/formats, languages, etc.).

GPI the translation agency has extensive experience interfacing with a variety of WCMS products in order to help clients author and publish multilingual content destined for an array of target formats.

The Sitecore WCMS platform is built on top of the Microsoft .NET stack of technologies, highly scalable and very easy to use. This blog focuses on some key considerations which should be addressed when preparing your Sitecore-powered website to store, author and publish multilingual content.

The Story

Throughout this blog post, we shall refer the following hypothetical scenario which outlines basic requirements for the development of a multi-language website in Sitecore.

Consider an international company which has offices in the United States (English), Argentina (Spanish) and Japan (Japanese). The company’s website is available in the three (3) languages and website visitors may switch between each language at any time while on the website.

Let’s assume the non-English versions of the website, should directly target their respective local markets and do not provide global company information. As such there is content in the English version which is not present in the other two versions.

Sitecore_translation

Designing your Information Architecture

For the purposes of this blog post, the term “Information Architecture” refers to the structural design of your content tree within Sitecore. The Sitecore content tree provides a hierarchical view of all your data management within the system. Each element within the content tree is referred to as a “content item“, which can have multiple version numbers and languages.

Typically the design of the content tree is done in the very early stages of the website development project. If a proper assessment of the website needs and goals are not conducted, the information architecture design can go through several iterations before it may be deemed as acceptable. The chosen design determines how developers utilize the content to present, determines how content can be presented in various ways, how content will be stored/retrieved/rendered and most importantly impacts on the website ability to scale well in the future to meet changing needs and demands. An information architecture which is not well designed around the full needs of a website can severely impact the cost-effective and time-efficient completion of a project.

While Sitecore supports multiple languages out of the box, considerations for delivering your website in multiple languages should be determined very early within the design phase of the project as well. Depending on the needs, objectives and constraints, the approach taken for multi-lingual support can vary vastly. Let’s consider the following scenario as an example for implementing a multi-language website using Sitecore:

Multisite Approach (i.e. One Language website per domain)

Sitecore provides a feature known as “Multisite”. This allows the administration and sharing of data between multiple distinct websites from a single Sitecore implementation.

In the “web.config” configuration file, Sitecore website administrators can enable different web sites for different domains in the same Sitecore structure. The sites configuration section contains a listing of website configurations Sitecore uses to host each website.

For the purposes of the multi-lingual website and the requirements stated above, the following shows an example of the “sites configuration” snippet of configuration for the English (“website_en”) version of the website:

<sites>
<site name=”website_en” virtualFolder=”/” physicalFolder=”/” rootPath=”/sitecore/content” startItem=”/home”
database=”web”domain=”extranet” allowDebug=”true” cacheHtml=”true” htmlCacheSize=”10MB” registryCacheSize=”0″
viewStateCacheSize=”0″ xslCacheSize=”5MB” filteredItemsCacheSize=”2MB” enablePreview=”true” enableWebEdit=”true”
enableDebugger=”true” disableClientData=”false”/>
</sites>

The following describes the attributes values which change when added the new “website_es”,
“website_ja” entries for the Spanish and Japanese websites respectively:

Attribute Name Description
name Name of the website
rootPath The path to the root item of the site (located within the Sitecore content tree).

The item path specified in the URL will be appended to this value to find the item.

startItem The path to the start item of the site (located within the Sitecore content tree).

This is used as the default item path if no path is specified in the URL.

It will be combined with rootPath to find the default item of the site.

hostName The host name of the incoming url.
language Default language for the site.

Therefore, a sample information architecture using this approach may look like the following:

/sitecore/
/content/
/website-en/ (English version)
/home/

/website-es/ (Spanish version)
/home/

/website-ja/ (Japanese version)
/home/

/common/ (data shared between each language version)

The corresponding “web.config” configuration file look like the following:

<sites>
<!-Japanese –>
<site name=”website_ja” hostname=”ja.website.com” language=”ja”virtualFolder=”/” physicalFolder=”/”
rootPath=”/sitecore/content” startItem=”/website-ja/home” database=”web” domain=”extranet” allowDebug=”true” |
cacheHtml=”true” htmlCacheSize=”10MB” registryCacheSize=”0″ viewStateCacheSize=”0″ xslCacheSize=”5MB”
filteredItemsCacheSize=”2MB” enablePreview=”true” enableWebEdit=”true” enableDebugger=”true”
disableClientData=”false”/>

<!-Spanish –>
<site name=”website_es” hostname=”es.website.com” language=”es”virtualFolder=”/” physicalFolder=”/”
rootPath=”/sitecore/content” startItem=”/website-es/home” database=”web” domain=”extranet” allowDebug=”true” |
cacheHtml=”true” htmlCacheSize=”10MB” registryCacheSize=”0″ viewStateCacheSize=”0″ xslCacheSize=”5MB”
filteredItemsCacheSize=”2MB” enablePreview=”true” enableWebEdit=”true” enableDebugger=”true”
disableClientData=”false”/>

<!-English –>
<site name=”website_en” hostname=”website.com” language=”en”virtualFolder=”/” physicalFolder=”/”
rootPath=”/sitecore/content” startItem=”/website-en/home” database=”web” domain=”extranet” allowDebug=”true” |
cacheHtml=”true” htmlCacheSize=”10MB” registryCacheSize=”0″ viewStateCacheSize=”0″ xslCacheSize=”5MB”
filteredItemsCacheSize=”2MB” enablePreview=”true” enableWebEdit=”true” enableDebugger=”true”
disableClientData=”false”/>
</sites>

Providing a Fallback Language

A “Fallback Language” is the chosen language and/or locale in which content is displayed if it is not available in the language selected by the user.

With reference to the requirements for the multi-lingual website above, if users were viewing the global information section of the English website and then switched to the Japanese equivalent there would be no content associated with it. The “Fallback Language” would then use the English content to render the pages since there is no content in Japanese or Spanish.

The Fallback language acts as a catch-all approach for any language missing in a particular version. However there may be constraints at the business level which mandates English content should be not available on the Japanese website while it is accepted to show English content on the Spanish website if content is missing. Ensuring that your website is culturally sensitive to the target market, and users are not confused with mixed-languages, is crucial website localization best practice and affects your approach in designing your multilingual websites.

The catch-all Fallback Language while a convenient short-term fix, should not be part of a long-term multilingual web content strategy.

Please make sure to read Part Two in the Sitecore Website Localization series entitled “Sitecore – Exporting & Importing content for Localization“.

Further GPI Resources on Connectors and Website Development

GPI offers custom CMS Translation Connectors to a variety of web content management systems in order to streamline localization workflows and access to translation project information across your enterprise. Connectors and Plug-ins include: