Let’s set the stage.
Jane, the global director of marketing has been told by her CEO that the top priority right now is better serving other regions. Jane and her team had just spent the last twelve months rebuilding the .com site and it has been performing quite well in the intended market, the United States. Jane understands the need to better support Europe, South America and Asia but is concerned that the necessary changes will impact all of the hard work that has been done to get the .com site ranking well in the major search engines.
Sitecore offers three choices for dealing with global Sitecore sites
The good news. Sitecore is quite flexible in the treatment of regionalized and translated content. Jane has quite a few choices. The following are all supported:
- Top level domains for each region, i.e. mycompany.de and mycompany.fr
- Sub-domains such as de.mycompany.com and fr.mycompany.com
- Directory structures such as mycompany.com/de and mycompany.com/fr
What is important to understand is that any well-built site in Sitecore can support one or more languages. When your sites are regional translations of your content and really a single site – that is, a single content tree with the items in multiple Sitecore languages - this has a huge upside for sharing content in markets with the same languages and product/service offerings.
If the regional sites have greater variation, in terms of content and purpose, distinct sites might make more sense. For companies that have vastly different product or service offerings in each region, this approach might be more beneficial and with a little planning, content sharing between sites is still possible.
Technical considerations for the Sitecore development team
Regardless of the approach Jane decides to take, her Sitecore development team needs to consider a few technical elements to ensure Google and other search engines can digest the content – which is necessary in order to preserve the hard-earned SEO ranking . Of particular concern in multi-region sites is informing the search engines that the content is not duplicated. This can be done for Google by using the hreflang attribute and specifying all variations of a page on each page. The following examples are for United States – English and United States – Spanish.
<link rel=”alternate” hreflang=”en” href=” http://example.com/us-en” />
<link rel=”alternate” hreflang=”es” href=” http://example.com/us-es” />
This can also be done using the XML sitemap format.
With Jane feeling comfortable that Sitecore can handle the content and will not impact the SEO performance of the original .com site in the United States, this then raises the even larger question - how to manage all of the regionalization of content? In some instances regional content is owned by the office in that country, but for others the corporate office in the United States (for example), is responsible for the content. This brings up the question of content governance.
Questions pertaining to content governance will need to be answered, for example:
- If content is produced in US English first, do we publish it right away or wait for all (or some of) the translations?
- What level of change in the primary language requires re-translation?
- Is any content produced in a language other than English first?
- Are the translators going to work directly in Sitecore?
All good questions. This is where planning of workflow becomes crucial. Too much and it cripples content author productivity, too little and the site content starts to deviate in quality and brand consistency. One provider for Sitecore that promises to lighten some of this burden is LionBridge. LionBridge Translation provides translation services, but they also offer a connector for Sitecore that can aid in the management of translation workflow. You can check out the details here.
Technical considerations when working with different versions of Sitecore
On a more technical note, there are some key distinctions among different versions of Sitecore to consider, particularly if using Experience Editor (formerly: Page Editor) heavily:
- Workflow and Default Workflow fields are shared in Sitecore 7 and 8. This means that the same workflow applies no matter the languages (the Current State Field can vary by language/version).
- Sitecore 8.0 introduced versioned layouts (a.k.a Final Renderings) which make usage of components more viable as a page design can vary by version or language.
- Sitecore 8.1 introduced a native language fallback mechanism, which we have covered here.
A final reminder for global Sitecore sites
Finally, when planning a global rollout, Sitecore developers must remember to update their Sitecore installation with local language packs. This update will allow regional content authors to work in a Sitecore interface in their own language. English, Danish, German and Japanese are available for almost all Sitecore versions. Other languages packs may be available for specific Sitecore versions.