Localization / Multilingual locales and current (interface) language vs current Multilingual site setting

[sneridagh]

In Plone, the concept "current" language is unified, and it controls which multilingual site are you in, and the language used thorough the site.

I think it's time to separate concepts so:

• Selecting the language of a site (eg. "I want to see the English version of this site"), via the language switcher or by navigating to it, doesn't mean I want the interface in English.
• It doesn't mean that I want the localized dates/times in the selected language (eg. for dates widgets, displayed dates etc)

I'm not 100% sure that it's achievable using Plone right now, since Plone unifies all of them, but we should be able reach to an acceptable point.

• We can try to introduce a “user preferred lang setting” (taken from browser/OS settings if not present)

• Then keep track of current language for the site that shouldn’t control the CMSUI language (eg Toolbar, forms) but it does control (and then I don't know if that's possible) the language of the literals is kept ("login", "register", etc)

[sneridagh]

Related:

1401

1400

[sneridagh]

I've just merged https://github.com/plone/volto/pull/1450

It assumes that the current language (for react-intl) is the language of the current object, matching Plone's behavior. Also I think it's a good sensible default.

We got wrong the defaultLanguage setting from react-intl-redux it should be fixed accordingly with the default language used through the translations, which in both Plone and Volto is 'en'.

[tiberiuichim]

+1 on this

[JeffersonBledsoe]

+1 on this. We've ran into some bugs around localisation of the admin interface (en is MM/DD/YYYY date formatting, causing great confusion amongst many other English speaking countries when trying to edit their dates) and being able to customise the admin language separately from the content language would have resolved the issue