- BLOB storage and providers
- Client resources
- Configuring episerver
- Configuring episerver.dataStore
- Configuring episerver.framework
- Configuring episerver.packaging
- Configuring episerver.search
- Configuring episerver.shell
- Configuring module.config
- Configuring staticFile
- Configuring episerver.basicAuthentication
- Configuring .NET SignalR
- Configuring Image Service
- Configuring link validation
- Reading application settings programmatically
- Page types and templates
- Block types and templates
- IContentRepository and DataFactory
- Persisting IContent instances
- ContentType attribute
- Grouping content types and properties
- EditHint in MVC
- Creating a page programmatically
- Selecting content
- Converting page types for pages
- Refactoring content type classes
- Multilingual content
- Assets and media
- Planning deployments
- Installing database schema
- Setting up multiple sites
- Content Delivery Network (CDN) Configuration
- Configuring your email server
- Automatic schema updates
- Storing UTC date and time in the database
- Database mode
- Deployment scenarios
- Dynamic content
- Dynamic data store
- Event management
- Scheduled jobs
- Search integration
- Searching and filtering
- Installing and deploying Search Service
- About Episerver full-text search client
- About Episerver full-text search service
- Configuring Episerver full-text search client
- Configuring Episerver full-text search service
- Searching for pages based on page type
- Adding search providers
- Authentication and authorization
- Virtual roles
- Configuring Active Directory membership provider
- Recommendations for ASP.NET security settings
- Securing edit and admin user interfaces
- Federated security
- Forms authentication
- OWIN authentication
- Configuring mixed-mode OWIN authentication
- Permissions to functions
- Protecting users from session hijacking
- Managing cookies on the website
- EPiServer AspNetIdentity
- Integrate Azure AD using OpenID Connect
- User interface
- Context-sensitive components
- Service locator
- Describing content in the UI
- Shell profile
- Store architecture
- Message service pool
- Publish and subscribe messaging system
- Introduction to Dojo
- Using jQuery
- Plugging in a gadget
- Creating a component
- Extending the navigation
- WebSocket support
- Dashboard gadgets
- Command Pattern
- Object editing
- User notifications
- Virtual path providers
This topic outlines some common globalization scenarios for Episerver CMS solutions, and provides an overview of language-specific settings and properties for CMS content.
Scenario 1 – global domain with multiple languages
You want visitors to go to the official site.com address, but need to display different content depending on their language selection.
- Set a default language that most of your visitors understand, (normally English for a global site).
- Activate language detection based on browser preference (pageUseBrowserLanguagePreferences="true" in web.config).
Testing the configuration
- Open a web browser, in this example Internet Explorer, and select Tools > Internet Options.
- Click Languages in the History group box and select the language preference. You are redirected to the correct language, if your language selection matches to a content language.
Scenario 2 – local domains mapped to languages
Use this approach when you want http://site.se to default to Swedish language without having the path in the URL contain the language. Add each host name and map them to a culture under "Manage Websites" in admin mode.
Scenario 3 – remember user preference
If you have a single domain and need to persist the user language preference, set a cookie with the current language selection. This means that the next time a visitor visits your site, the visitor is redirected to the correct language. 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 make sure that 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 therefore be unique: two language branches cannot use the same language code because the reverse lookup would fail.
A content item, for instance 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, both properties for that language and common properties. When new languages are created for a content item, each saves only properties that are specific 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.
Language-specific properties are defined by the administrator/developer on a content type. The metadata (for example, Name) that is language-specific cannot be changed and was defined by the system. Metadata properties that relate to content are language-specific and metadata properties that relate to navigation are common.
For PageData, the following properties are defined per language:
- PagePendingPublish endingPublish
You can programmatically check if a property is language-specific by checking IsLanguageSpecific on the PropertyData class.
Content language settings
To determine the languages to use on which part of a site, use the Content Language Settings, which define the languages that are available to the editor when creating new content. The settings also define fallback languages and replacement languages. The administrative API for content language settings are settings are EPiServer.DataAbstraction.ContentLanguageSettingRepository. The runtime API to read settings with support for inheritance is EPiServer.Core.IContentLanguageSettingsHandler. Page Language Settings do not restrict the languages that are rendered on the site; it only helps Episerver make choices based on custom settings.
Note: Language settings are currently only available for pages and not other content types like blocks.
Language options in the API
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 has been published (CurrentPage.PendingPublish is false). The language selector does not check publish dates, so for example when a news item expires on one language, it is no longer displayed (no fallback to another language is applied).
Dynamic properties (Legacy feature)
You can make dynamic properties available per language. Dynamic properties do not use Page Language Settings and are always loaded with the same language as the page. For example, a Swedish page always 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 archive page, all Stop publish dates for all languages are cleared.
Web browser preference
The web browser sends headers that inform the site of the languages that the user prefers. For example on a Swedish Internet Explorer the header contains SV. If this feature is enabled in web.config/System Settings in the admin view, Episerver CMS tries to match this value to the language code that is enabled as a website language. An exact match is preferred, such as a visitor with language preference English New Zealand (EN-NZ) tried to get an exact match, but falls back to English (EN) if found instead.
Always use the ISO language codes, but to enable the fallback of user preference you may want to use language code EN for the English version that should be master-English.
The PageSearch search control supports searching on either all languages or a list of defined languages. The actual search does not use Page Language Settings as part of the search query, but uses Page Language Settings when selecting which language version of the page that should be displayed to the visitor.
No special treatment occurs for files, so if you have language-specific files, you must separate them in different directories.
Property searching (FindPagesWithCriteria)
The PropertySearch search control and the underlying APIDataFactory.FindPagesWithCritiera search on all languages by default. However, the hits use the same language selection process as any other page loading. You can control the following parameters:
- Search only on a specific language.
- Pass in language selector which is used when returning the actual pages.
This lets you find a property that is only on a specific language branch.