Page History

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 new/returning internet user – public user – will most likely be able to see and interact with only the pages of a published web project. Such a user will – via the web browser – communicate with a running public instance of Magnolia. A public user, for example a user who's native language is Italian English and who visits and interacts with a web project website built with Magnolia will usually prefer if the website's language were also Italian.English (the screenshots are from the Travel Demo):

Image Added

On the other hand, an editor/publisher (user) or sysadmin – system user – working with the author instance of Magnolia may have different locale preferences than the public user. A content editorThe system user's native and hence preferred language may be, for example, Spanish , but the content being edited may still be in Italianthe English language. Such an editor will would probably welcome if the system messages, app and action names in the author instance (see also Types of translatable text) would be displayed in Spanish rather than in Italian.English:

Image Added

Magnolia has been built to deal also with these two locale (or more narrowly language) preferences:, that is with 

• The locale of a website.site locale, and 
• The AdminCentral locale of the AdminCentral.

Determining and setting the AdminCentral locale 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 ask a user with superuser rights to set the preferred locale for them. Determining the preferred locales of the public users who interact with a Magnolia website is not that transparent since they will usually access the website locale for a site is less transparent 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 a public user.

And a li

Open point: proper naming for the 2 different locales.
Tmp names for this tmp page to be reused among this page:

• UAdmin-locale
• client-locale

Locale of the AdminCentral

users.

AdminCentral locale

AdminCentral locale primarily sets AdminCentral's language setting is primarily used to define the language of User interface labels that the user of AdminCentral wants to see and work with, such as 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 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). 

...

To display content to the client in the proper language, used for editorial content, template labels

Configuring the locales

With the configuration you define a set of possible languages plus a default language.

<We may or may not explaining here the config. depth. It also could be sufficient to link to the sections where it is already explained>

...

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 available system languages (see further below) or it will fallback to English. 

...

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

Site locale

The setting of site locale influences the editorial content and template labels.

Determining the

...

locale for a site

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:

...

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).<in progress>

Configuring a site locale