Page History

This page describes two different types of language locale in Magnolia and how to configure Magnolia for them. The two locales influence the rendering of content in the AdminCentral and on a published page.

What is locale

Two locales in Magnolia

The question of "two locales" is connected with the types of users who access a Magnolia instance.

...

To determine public locale is slightly more difficult. Visitors usually access web content as anonymous users. Magnolia then has to rely on indirect means that point to the preferred locale of a visitor.

AdminCentral locale

The AdminCentral locale primarily defines the language of User interface labels which the AdminCentral user wants to interact in with the AdminCentral. This concerns, for example, the language of labels in the Action bar (English on the left, Korean on the right):

...

An incomplete localisation of a UI element may result in displaying a label in the fallback language, as shown below in the case the Copy page and Paste page actions:

Setting and configuring the AdminCentral locale

When logged-in in the AdminCentral, its users may set their language locale parameter via the Language field in the Edit user profile dialog. The setting will be reflected in the names of action menus, actions, buttons and labels throughout the AdminCentral provided the locale is one of the available system languages or it will fallback to English, the default fallback language (see also the configuration of available system languages and fallback language configuration).

...

The new locale will be applied the next time you login to the AdminCentral.

Public locale

Public locale influences the editorial content and template labels rendered on a visitor's device. Unless a visitor registers to a product or service and actively provides the preferred locale information, the public instance has to rely on other means that help identify the visitor's preferred locale.

Determining the preferred public locale

There are a number of ways of obtaining some form of locale information. Some of them use advanced techniques such as geolocation based on ping delay or topology, but one of the most common way is to look into the content of an HTTP request. At least the following three parts of an HTTP request are relevant to the identification of the public user's locale:

• the User-Agent header
• the Accept-Language header

• Request-URI

From the User-Agent header

While occassionally containing information such as en_US , for example in 

...

Magnolia has no ready-made means how to check for the existence of and retrieve this type of locale information. The preferred locale information is communicated via the Accept-Language header.

From the Accept-Language header

The Accept-Language request header of an HTTP request defines which language variant of the page is preferred by the public user. This locale information may take one of the following three forms:

...

A site in Magnolia may be configured to reflect the locale information provided in the Accept-Language header,  see RequestLocaleAwareI18nContentSupport in the configuration section below.

From Request-URI

The most common form of Request-URI is that used to identify a resource on an origin server or gateway. For example:

...

To configure a site in Magnolia to parse Request-URI for locale preference, see DefaultI18nContentSupport and HierarchyBasedI18nContentSupport in the configuration section below.

Configuring locale for a site

The configuration that defines the locale information for a site is usually located:

...