Handling Languages

Table of Contents

• Introduction
• Determing Content Language
• Determing User Interface Language
• Determing System Language
• See Also

Introduction

To make the process of handling languages more robust and consistent, EPiServer CMS introduces some minor changes. The following article is a description of how language settings are handled in this release.

Types of Language Settings

• User Interface Language. Controls the localized resources to display. This means that it determines the language of the edit and admin user interface, and any other place where calls are made to retrieve and display localized texts. Starting with the EPiServer CMS 7 release the preferred way to retrieve localized string resources are through the LocalizationService API. For information on how to use the LocalizationService, refer to the section "Using the Localization Service" in the EPiServer Framework SDK.
• System Language. Used to control date/time formating, sort order etc.
• Content Language. The preferred language when displaying content. Note that the actual content language is eventually determined by a LanguageSelector and is dependant on the languages available for the pages that are displayed.

Vocabulary

• Culture. An instance of the CultureInfo class. The preferred way of passing language information in EPiServer.
• Locale. Never explicitly used in EPiServer, except where locale is required by other components. In this case the locale is read from the LCID property of the required culture, usually CultureInfo.CurrentCulture which corresponds to the System Language.
• Language code. A string that defines the culture to use. See CultureInfo.Name for definition and possible values. If you cannot pass a CultureInfo object, this is the alternative way of specifying language/culture.
• Candidate match. A lot of language selection algorithms will make use of "candidate matches". This means that if you have a language code "en-GB", then language code "en" would be a candidate match. Another possible candidate match for "en-GB" would be "en-US". This means that a candidate match is the first language code that matches the substring before the hyphen.

Determing Content Language

Accessing

The current value can be determined by reading ContentLanguage.PreferredCulture. You can change the value by assigning this property.

Selecting

1. Compile a list of preferred languages in priority order:
   
   1. If the query string parameter "epslanguage" exists, add the language code to the list.
   2. If admin or edit page and the "editlanguagebranch" cookie exists, add the language code to the list.
   3. If the web.config parameter domainLanguageMapping is set and we have a match from the host name, add the language code to the list.
   4. If the cookie "epslanguage" exists, add the language code to the list.
   5. If the browserLanguageDetection setting is enabled, get the entire list of Request.UserLanguages into the list.
2. Get a list of all available content languages, enabled or not, (LanguageBranch.List()) and pick the first language from the preferred list that has an exact match in the content language list.
3. If no match found in the previous step, use the first candidate match(*).
4. If no candidate match found, use the first language returned by the list of available and enabled content languages.

Modifying

The selection algorithm outlined above is implemented in ContentLanguage.DefaultContentLanguage and can be overridden by inheriting from ContentLanguage and assigning an instance of the new class to the static property Instance on ContentLanguage.

Determing User Interface Language

Accessing

The current value can be determined by reading CultureInfo.CurrentUICulture and set by setting Thread.CurrentThread.CurrentUICulture. The information is a CultureInfo object and the language code ("en", "sv" etc.) can be retrieved from CultureInfo.Name.

Selecting

1. Compile a list of perferred languages in priority order:
   • If viewing a template, add the current content language code.
   • If there is a language setting in the personal profile, add it to the list.
   • Use system default as set in web.config, <globalization uiCulture="xx">, which may be auto in which case it reads the browser language preferences.
2. Get a list of all available User Interface languages (LanguageManager.GetLanguages()) and pick he first language from the preferred list that has an exact match in the UI Language list.
3. If no such match exists, use the first candidate match (*).
4. If no candidate match exists, use the first available user interface language.

Modifying

In case you want to customize the selection logic, you can modify CurrentUICulture in the InitializeCulture() method (virtual method on System.Web.UI.Page). Our default implementation is done in EPIServer.PageBase.

Determing System Language

Accessing

This current value can be determined by reading CultureInfo.CurrentCulture and set by setting Thread.CurrentThread.CurrentCulture. The information is a CultureInfo object and the language code ("en-GB", "sv-SE" etc.) can be retrieved from CultureInfo.Name.

Selecting

Compile a list of preferred languages in the following priority order:

1. If viewing a template, use the current content language code if language code is valid(**).
2. If there is a language setting in the personal profile, use it if language code is valid(**).
3. Use system default as set in web.config, <globalization uiCulture="xx">, which may be auto in which case it reads the browser language preferences. Since this culture has been set at the very start of the request, this step is really a "do nothing".

(**) Valid means that there is a CultureInfo with the specified language code and that the language is not a neutral culture.

Modifying

In case you want to customize the selection logic, you can modify CurrentCulture in the InitializeCulture() method (virtual method on System.Web.UI.Page). Our default implementation is done in EPIServer.PageBase

See Also

Writing Culture-Safe Managed Code