Globalization scenarios

You want visitors to go to the official site.com address, but you want to display different content depending on their language selection.

Use this approach when you want http://site.se to default to the Swedish language without having the path in the URL contain the language. Add each hostname and map them to a culture under Manage Websites in the Optimizely Content Management System (CMS) admin view.

If you have a single domain and must persist the user language preference, set a cookie with the current language selection. This means the visitor is redirected to the correct language the next time a visitor visits your site. You also may use this to redirect the visitor to another system where language preference is not retained in the URL. You can set a cookie named epslanguage to ensure the visitor gets the same language as before when returning to the site.

A language branch has a unique identifier in the database to handle constraints but is always exposed in APIs as a language code, for example, EN. Language codes must be unique: two language branches cannot use the same code because the reverse lookup would fail.

A content item, such as a page, is created on a language branch, and the first language created becomes the master language branch for that content. This applies to all content, globalized or not. The master contains all properties for that language and common properties. When languages are created for a content item, each saves only specific properties for that language.

As a developer, languages contain the common properties from the master version in the object, but they are not editable. If you change a property that should not be saved per language, an exception occurs when you call the IContentRepository.Save method if the language you are publishing is not the master language for that content.

The administrator or developer defines language-specific properties on a content type. The metadata (for example, Name) that is language-specific cannot be changed and was defined by the system. Metadata properties related to content are language-specific, and metadata properties related to navigation are common.

For metadata properties, the following properties are defined per language:

You can programmatically check if a property is language-specific by checking IsLanguageSpecific on the PropertyData class.

To determine which languages to use on which part of a site, use the Content Language settings, which define the languages available to the editor when creating content. The settings also define fallback languages and replacement languages. The administrative API for content language settings is EPiServer.DataAbstraction.ContentLanguageSettingRepository. The runtime API to read settings with support for inheritance is EPiServer.Core.IContentLanguageSettingsHandler. Content Language settings do not restrict the languages rendered on the site; they only help Optimizely make choices based on custom settings.

Languages are selected at runtime using a language selection process. You can customize the options used for the language process by using the LanguageLoaderOption passed to IContentRepository.

A language is considered available by the language loader if it was published (CurrentPage.PendingPublish is false). The language selector does not check publish dates, so for example, when a news item expires in one language, it is no longer displayed (no fallback to another language is applied).

You can make dynamic properties available per language. Dynamic properties do not use Page Language settings and are loaded with the same language as the page. For example, a Swedish page gets Swedish dynamic properties (even if displayed on an English site due to fallback configuration).

A page is archived when an archive page is set and the Stop publish date has passed. In the process, the Stop publish date is cleared. On globalized pages, you have multiple Stop publish dates, but only the master language Stop publish dates are checked, and when the move is made to the archive page, Stop publish dates for languages are cleared.

The Web browser sends headers informing the site of the user's preferred languages. For example, the Accept-Language header might contain SV for a Swedish user. If this feature is enabled in GlobalizationSettingsOptions.UseBrowserLanguagePreferences, CMS tries to match this value to the language code enabled as a website language. An exact match is preferred, such as a visitor with a language preference in English New Zealand (EN-NZ) trying to get an exact match but falls back to English (EN) if found instead.

The IPageCriteriaQueryable searches all languages by default. However, the hits use the same language selection process as any other page loading. You can control the following parameters:

This lets you find a property only on a specific language branch.