Site and AdminCentral locales

What is locale

Not one but two locales

Typically, Magnolia runs on two instances, the author instance and the public instance and the question of "two locales" is connected with the types of users who access a Magnolia instance.

An ordinary internet user, new or returning – whom we can call a public user – will usually only be able to see and interact with the pages of a published web project or website. The user will be interacting – via the web browser – with a running public instance of Magnolia and will expect that the content of each page on the site will be available in a language he can understand, ideally in his native language.

For example, a user who's native language is English will prefer browsing the English language version of a website (the screenshots are from the Travel Demo):

On the other hand, a Magnolia editor/publisher (user) or sysadmin – let's just simplify these roles to a system user – working with the author instance of Magnolia may have different locale preferences than the public user. 

For example, a system user's native and hence preferred language may be Spanish but the content being edited may still be in the English language. Such an editor would probably welcome if

• Field labels and descriptions,
• Messages (alerts, warnings, information),
• App UI elements such as workbenches, columns, forms and actions, and 
• Buttons in the page editor in edit mode, used to open dialogs

in the author instance (see also Types of translatable text) were displayed in Spanish rather than in English:

Magnolia has been built to deal with these two separate locale preferences, that is with 

• Site Locale
• AdminCentral Locale.

Determining and setting the latter is fairly straightforward since the system users will usually know which locale they prefer. They can also set the locale themselves directly in the AdminCentral or they may always ask a user with superuser rights to set the preferred locale for them.

To determine the locale for a site, in other words, to specify the language in which a public instance should send page content to a public user is slightly more difficult since public users usually access web pages as anonymous users. Magnolia then has to rely on indirect means that point to the preferred locale of public users.

AdminCentral locale

The AdminCentral locale primarily defines the language of User interface labels that the system user wants to work with in the AdminCentral, for example the language of labels in the Action bar (English on the left, Korean on the right):

AdminCentral's time zone setting, on the other hand, has an effect on the content of, for instance, the date field before any date is entered in it. The field shows a pseudo-placeholder text that changes according to the actual (user's) time zone setting, compare:

Surely, two different English-speaking editors, one working in London and the other one working in Berlin, will want to use their local times in many instances of such a field. In addition, the form of the timezone placeholder depends not only the time zone setting, but also on the language setting described just above. If the preferred working language of one of the editors is set to German, the hint will show MEZ (abbrev. of Mitteleuropäische Zeit) instead of CET (abbrev. of Central European Time). 

Configuring the AdminCentral locale

When logged-in in the AdminCentral, users may set their locale via the Language and Time zone fields in the Edit user profile dialog. The language part of the locale 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 (see further below) or it will fallback to English. 

To set a locale, open the pull down menu in the top right corner of the browser window and click the first row of the menu, titled Edit user profile if the current locale setting is English. On the Preferences tab:

• Choose a language in the Language field:
  
  With superuser role you may set language locales for other users, see Setting an editor's language preference.

• Choose a timezone in the Time zone field. 

The new locale will be applied the next time you log in into the AdminCentral.

Site locale

The setting of a site locale influences the editorial content and template labels and unless a public user registers to a web product/service and actively provides the locale information to the webapp, the webserver has to rely on other means that could help identify the visitors preferred locale.

Determining the locale for a site

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 HTTP headers that request a web page from the public instance. At least the following three headers are relevant to the locale identification:

• User-Agent
• Accept-Language
• Path

The first one 

The Public instance delivers the final page to a page visitor, and tries to deliver it in a way that fulfills the content of the HTTP request for the page. A part of the HTTP request's header defines which languages the visitor (client) is able to understand, and which locale variant of the page is preferred. The part that does this is the Accept-Language request header and may take one of the following three forms:

• <language>
• <locale>
• *

The first represents language expressed as a 2 or 3-character string, the second represents language as a full language tag, the third says "any language" (see Accept-Language and Language Tags in RFC-2616).

Configuring a site locale