Best Practices for Sitecore Internationalization, Part 2

This is the second part of a series of three blog posts about the best practices for Sitecore internationalization. In this blog, we’ll introduce a few aspects that are important to define early in the development process of your multilingual website.

Language Hierarchy

One of the main aspects to define before creating a multilingual website is the language hierarchy. Depending on your language requirements, you may or may not need different variations of each language. For example, if your website is targeting audiences in England, the United States and Australia, you may want to have different variations of English or you may want to have one form of English that applies to all these countries. This will depend on the level of personalization that you want. This same example applies for Spanish, which can vary if you target Latin American countries or Spain or you could use a universal Spanish for all Spanish-speaking languages.

By using Sitecore’s language fallback feature, you can have a base English version of the site and variations of English for each region. For example:

Another aspect to evaluate for language hierarchy, other than the language needs, is the website structure for each region. If your website will show different content depending on the region, it’s good to have a hierarchy that is based on regions. For example, if you are planning to have website content for Europe, the United States and Asia, you could have a structure like the following:

Sitecore is flexible when defining a language’s hierarchy and you can build a hierarchy that addresses your specific needs.

Shared Fields

In some cases, you will have fields that you don’t want to have translated or differentiated per language. For this, it’s recommended to configure these fields as shared. This is something that you need to define at the template level (there is a checkbox that allows you to specify if a field is shared or not). Shared fields are shared among all languages and all versions. So, if you change the value of an item on a specific version, it will be reflected in all versions and in all the languages.

Having fields defined as “shared” will stop most translation tools from translating them, as by definition, these fields are not translatable.

UI Fonts

An aspect related to front-end development is the decision of which fonts to use. It’s common in actual website development that designers use different fonts for each section of the site (one for titles, another for body text, another for buttons, etc.). The decision of which fonts to use can lead to issues when building multilingual websites, so it’s important to have this decision made ahead of time.

Not all fonts support all of your target languages. Pay attention to languages that use diacritical marks, like Spanish, and to languages that use Cyrillic characters, like Russian.

A best practice for font selection is to use Unicode, a consortium that approves universal character encoding standards for different languages. This will allow you to select fonts that are fully Unicode-compliant.