Multi-lingual and multi region website in Sitecore for Global brand

 

Overview

This document is intend to provide guideline to understand requirement of the multi locale, multi brand and multi lingual capability. In the other section of the document there is guideline how to design architecture of the website which is having requirement of Multi locale, brand and language.
Requirement

• 1. Multi Locale
When delivering contents in multi locale and multi lingual site we have to be aware that, apart from the mere translation, other adjustments, such as date and number formats, currency have to be made. The topics Internationalization and localization are extensive cross-section concerns, where the implementation is definitely not trivial. Locale languages on Sitecore use the format ll_CCc, where ll is a two-letter language code, and CC is a two-letter country code. For instance, en_US represents U.S. English. Sitecore support many ISO languages and country codes Multi-locale should support all data Format 8 byte (UTF-8) encoding. We might need to change default settings for systems that process client requests and forms data that use non-UTF-8 local code pages. For example:
• • A single-byte Latin character set, such as Spanish, French, or German
• • A multi-byte character set, such as Japanese or Chinese
We should think of having following business cases is being captured in multi locale design:
• • A site can be managed in any number of cultures (for example, US English).
• • Every field on a template can be marked as unique to a specific language or shared across all languages. For example, a company logo would be common to all languages and on the same item a different field can be unique in any language.
• • Each language has its own version history.
• • Items can be pushed through workflow to incorporate the translation process.
• • When implemented properly, a site will not require software changes to support new languages.
• 2. Multi Brand
A well-executed localization strategy presents the brand in the context of the market we’re in, and extends well beyond just language. International appearance of a brand with brand specific features in the individual countries is feasible by considering there global requirement and local requirement very clearly. As an orientation guide for the decision making process we should ask business if there will be structural differences between the individual sites. Is there a difference between navigation and number of pages and might those even use different specific templates? Then the decision should clearly be the second version for internationalization in SitecoreWebsite branding (which includes its logo, theme, font, asset, language layout, spelling and images) is having its very critical business value and we need to assess the brand for multilingual site. This could be same or change for few place different for all country. Few organizations have country specific brand and its content with multi-lingual requirements so for these kind of organization will require country specific localization.
• 3. Multi Lingual
• We will have requirement where we need to develop multi-lingual site. We need to understand the multi-lingual feature of any business. An organizations is having consistent brand across the globe and are centralized enough that a single, multi-lingual site meets the business needs.
• We need to identify what fields should be multi-lingual ready; as not all fields should. The more we have shared fields the less we will have effort in translation
• We should not consider machine translation options, there should be content translation and the workflow process should be there. Regardless of whether translation is managed internally or outsourced to a service, we’ll need to wrap a workflow around the process.
• We need to determine at the outset whether we'll be dealing with translated content or localized content as this distinction will heavily influence our data/information architecture. Translated content is content that has been translated from a source language to a target language, often in a very literal word for word fashion. Localized content is translated content that has been adapted to meet language, cultural and other requirements of a specific target locale. Translated content is typically better suited for multilingual sites that can use the same content tree for each implemented language. Localized content is often better suited for separate content trees.
• The language fallback option should be there so if the content is not available in respective language then it should have something to display in default language
• We should have dictionaries for all labels and other dynamic or static elements of pages as much as possible
• We need to ensure that the media library should be organized to ensure reuse of media assets where applicable.

Checklist for Implementation
• 1. Language Variants:
The first thing to do in our Sitecore project is to ensure we have the language variants configured in your system. We need to add the other languages at our website as per need. To configure the language options on the drop down: • In the content editor go to System > Languages • Right click the language node and choose Insert LanguageA predefined language code drop down lets you pick between a set of predefined languages

• 2. Content Tree Design:
The IA for website should designed in such a way that it is country specific then it will have content structure redundant in nature but that is what we require from maintenance point of view. So if there is any content authoring would not impact other country brand site. We could think about a structure with a Global node under Content, which will contain our default website for multiple locales and then, at the same level, a new node for each specific locale that needs to be considered separately, for example, Global , Mexico and for other country specific site.

If this is multi lingual site then there would be unique content tree structure available for all language, it will have different version of different language in same The way you architect your content tree in Sitecore should be determined by a series of inputs and variables. Local-content: In order to make shared content more manageable, we have to create a Local Content folder under each website, with Sitecore 8.2 we have local datasource concept for same, and all the local product in a Products folder. Now we still have the separation between data and presentation, but we are still inside the context of the current site. The resolving of the wildcard for local products will be unchanged. We only have to set the data folder of the Products to the local products folder.

• 3. Templates
When selecting a template for website, it’s important to keep in mind that not all templates work equally well with global websites. Text translated into a specific language doesn’t necessarily have the same length as the text in the source language. Using a template that doesn’t adapt to different text lengths could cause the text to be displayed incorrectly, with some overflows or incomplete sentences. Additionally, there are some languages that follow some specific rules, for example, Arabic, which is displayed from right to left. In some instances though content will contain fields which should remain the same across all language versions. This could be for product sku’s, dimensions of an object or possibly image fields. Typical Template structure for multisite structure:

To make a field share it’s values over multiple languages, in the template definition tick the shared checkbox against the field.

As a result selecting a template that isn’t built with these kind of details in mind, can introduce a number of issues when introducing translated content into our website.
• 4. Language resolver:
Language resolver ensure that whenever we will switch the language the Sitecore Context will have updated language. The Sitecore layout engine retrieves content from the Sitecore repository in the context language (Sitecore.Context.Language). The default logic to determine the context language is to use the first of these variables that specifies a value:
• The sc_lang query string parameter.
• The language prefix in the path in the requested URL.
• The language cookie associated with the context site.
• The default language associated with the context logical site.
• The DefaultLanguage setting specified in web.config.

In the first two cases, Sitecore generates a session cookie so that subsequent requests do not have to include the URL query string or language prefix in the URL. If the user returns to the site without specifying the URL query string parameter or the language prefix in the URL path, their language selection would be lost. If the organization has not published a translation of the context item in the context language, Sitecore acts as if all fields in that item are empty. Some solutions need to augment the default logic for determining the context language. For instance, the developer may want to:
• Consider the browser's language preferences.
• Fall back to an alternate language if the organization has not published a translation for the requested language. For example, if the browser requests Austrian German, but content does not exist in that language, but does exist in German German, the developer might want to use German German instead of the default language associated with the context site. Fall back from one language to another until content exists for a language, or use the site's default language.
• If no content exists for the item in any of the languages investigated, but content does exist in some other language, use that language.
• Use a persistant cookie.
In multi-lingual site url would be like http://mydomain/fr. The thumb rule is that language resolver should set right context of the language based on change in language. To cater custom requirement like serving the language from browser context we need to override the LanguageResolver in include config:
MyLibrary.Pipelines.HttpRequest.LanguageResolver, MyLibrary
We need to write the pipeline i.e. the class that rewrites the functionality of the stock Sitecore LanguageResolver.
• 5. Content translation:
Sitecore provides Out of the Box(OOB) feature to create content in multiple language by content editor. Accessed from the Versions Tab in Content Editor – this handy interface allows a suitably skilled content editor/translator to view the source language while translating into the target language in real time.

However – for anything more than a page or two – this manual approach raises some serious challenges.
• we’ll need to license Content translator so Content translator can access Sitecore
• we’ll have to train Content translator on how to use Sitecore Content Editor
• Content translator will need fairly deep access to your content
There are some third party content translation agency which provide there service as per the requirement. One of them is GPI , they provide Sitecore connector to establish the content flow between agency and Sitecore. The connector work in three different step:
• Export content.
• Deliver to your Translation Provider
• Return Content into Sitecore.
The best architecture is to use an intermediary layer that abstracts the Sitecore connection from the translation connection – allowing systems to be mixed and matched. The routing logic in that connectivity platform can send content to various translation providers based on things like target language. There should be proper security channel, use an SSL connection and encrypt files while they’re in transit to be safe.

• 6. Fallback:
Language fallback is the property which we can configure at item and it’s field level to ensure that the content is available, if it’s not there in respective language it will get it from fallback. We can also set up a chain of language fallback. For example, we can specify the language en-NZ to fall back to en-AU and en-AU to fall back to en. If the version in en-AU does not exist for a particular item or field, then the version in en-NZ falls back to the version in en.

We should not use both item- and field-level fallback on the same items at the same time because it makes it difficult to keep track of how language fallback affects your items and fields. Item-level fallback enables you to set up an 'empty' item version in a given language so that it falls back to another language version, including all its fields. In this way, you can launch a new language version of your entire website without creating any items in the new language in the Content database. In the Content Editor, Version drop-down list, Fallback version is displayed. Field-level fallback enables Content Editor(CE) to specify on a single field, which field values that CE want to localize and which field values that he wants to fall back to another language. If we set up field-level fallback, on the individual field, we can see that the value is a fallback value from another language version and from which language, for example (en).

Tech team can also use the language fallback feature on all dictionary labels on a website. Item-level fallback is enabled by default on the template that dictionary entries are based on.
• 7. Language Security and Access:
We need to implement proper roles and rights in content tree based on language. This will help to avoid any kind of language mess-up while content authoring. We can provide language read/write restriction in different scenario like: • Some language-specific content is sourced through a single entity and you want to protect it from modification. • We have a large number of languages installed but most languages are not relevant to most authors. So this will provide access to content authors only to see two languages: Their native, (hopefully regionalized) language and whatever language is used as the corporate standard. The another benefit would be by restricting Language-Read access to just two languages will remove a large amount of visual clutter from the local content author’s editor, making their job easier.
• 8. Locale:
The Local implementation is typical culture driven and based on “LL-CC” code we would be handle to handle all the locale specific information like date time, Currency and number format. We have OOB the Sitecore culture api which supports ISO code and manage the data automatically like dateformat, ,currency and numeric format if we have taken the input using this api in ISO format.
• 9. Brand Asset
Brand assets and related items are different from normal website assets and content. This is having direct impact on business values. The Sitecore Experience Platform (XP) empowers us to market in context of current and past customer interaction with our brand, across any channel and any country in real time.Branding can impact our site analytics and business values.
• 10. Localization of Web Forms for Marketers
We can localize web forms by translating individual field names and other form information to other languages or dialects. The web forms created in the Web Forms for Marketers module can be fully translated into other languages. We can localize a web form field, save action, success message, or form verification message and error message. To do the same: 1. Open the relevant form in the Form Designer. 2. In the Language group, click the current language to display a list of the language versions that are available and select the language you want to translate the form to.

3. Enter the translated text for the fields in the form. By default, the first time the form appears the field names are blank with a help text in the original language. Unnamed fields and sections are deleted from the form.