[MGNLEE-200] DefaultLocale and fallbackLocale dont behave as expected when creating a new Site definition Created: 19/Apr/11  Updated: 28/Aug/14  Resolved: 29/May/12

Status: Closed
Project: Magnolia DX Core
Component/s: None
Affects Version/s: 4.4.2, 4.5.2
Fix Version/s: 4.5.3

Type: Bug Priority: Neutral
Reporter: Samuel Schmitt Assignee: Eric Hechinger
Resolution: Fixed Votes: 2
Labels: i18n, site_definition
Σ Remaining Estimate: Not Specified Remaining Estimate: Not Specified
Σ Time Spent: Not Specified Time Spent: Not Specified
Σ Original Estimate: Not Specified Original Estimate: Not Specified

Attachments: JPEG File sitedef.jpg     Text File stacktrace.txt     Text File stacktrace.txt    
Issue Links:
Cloners
is cloned by MAGNOLIA-4421 CLONE -DefaultLocale and fallbackLoca... Closed
duplicate
is duplicated by MGNLETK-79 Templates and Resources files cannot ... Closed
relation
is related to MULTISITE-22 Edit mode locale selector is not popu... Closed
supersession
is superseded by MGNLUI-3128 FormBuilder: defaultLocale in dialogs... Closed
Sub-Tasks:
Key
Summary
Type
Status
Assignee
MGNLEE-228 Creation of a new component for Multi... Sub-task Closed Eric Hechinger  
Template:
Acceptance criteria:
Empty
Task DoD:
[ ]* Doc/release notes changes? Comment present?
[ ]* Downstream builds green?
[ ]* Solution information and context easily available?
[ ]* Tests
[ ]* FixVersion filled and not yet released
[ ]  Architecture Decision Record (ADR)
Bug DoR:
[ ]* Steps to reproduce, expected, and actual results filled
[ ]* Affected version filled
Date of First Response:

 Description   

Create a new Site Definition (not an extension of the Default).
Add two locales:DE & FR.
Set DE as defaultLocale.
Set DE as fallbackLocale.
(see attached file)

Then edit the properties of a page (like the title) in the german edit mode.
In the corresponding node is created a property 'title_de', but 'title' was expected (as DE is the default and fallback locale).



 Comments   
Comment by Jan Haderka [ 19/Apr/11 ]

Don't forget to mention that to reproduce such scenario, there needs to be also "default" site configuration which has different setting from your own and that neither of the sites have assigned domain.

When there is only one site definition or when there is a domain assigned to site, everything behaves as expected.

Also please attach a log from the instance when trying to access the page in question with debugging enabled on multisite filter.

Comment by Richard Unger [ 09/May/11 ]

What is happening is the following:

  1. info.magnolia.cms.gui.i18n.DefaultI18nAuthoringSupport is responsible for the i18n in Dialogs, see method i18nIze() of this class.
  2. In line 04, the method retrieves the fallbackLocale from the i18nContentSupport object, a final field of the class DefaultI18nAuthoringSupport which is initialized in the constructor.
  3. In lines 13-16, the suffix is only appended to the property name, if the dialog’s locale is different from the fallback locale.
  4. In Magnolia EE, each site can have a different i18n configuration (each site has its own i18nContentSupport object associated with it).
  5. However, the i18nContentSupport object is only initialized in the constructor, and is final after that. Also, DefaultI18nAuthoringSupport itself is only initialized once, close to server startup (on first page request?).

Therefore, when the dialog is rendered, the i18nContentSupport object used is NOT THE CORRECT ONE FOR THE WEBSITE in which the edit is performed.

I verified this by subclassing DefaultI18nAuthoringSupport, overriding i18nIze() and outputting the values of fallbackLocale and locale.
It is the case that despite my site having fallbackLocale “de”, the fallbackLocale output by i18nIze is “en”. I assume at initialization time, DefaultI18nAuthoringSupport is grabbing a default configuration, rather than the one for my site definition.

Since the “demo-project” uses fallbackLocale “en”, which is also the default, everything works fine for “demo-project” i18n.
In sites which use a different fallbackLocale, you will see an error.

Personally, I think it is a very bad idea to store some content in nodes with suffixes, and some without. It certainly means you can’t change your i18n configuration once you have content! Personally, I think it would be much better to remove the check for defaultLocale (line 13, below), as far as I can see this would make everything work correctly.

However, if it is really desired to store the fallbackLocale without suffix, then i18nIze needs to check the site’s i18n configuration, and not use a default initialized at startup. That works for CE, but not in EE with multi-site.

Retrieving the correct i18n configuration probably can’t be done in the normal way, (see ETKI18nContentSupport.getI18nSupport() ), since this depends on the aggregation state, which (I assume) will not be set up right when the request is to the edit-dialog rather than rendering content. Probably a new method is required which gets the i18n configuration of the site to which the node being edited belongs.

But I do really think it would be much better NOT to remove the suffix for the fallbackLocale.

 

01    public void i18nIze(Dialog dialog) {
02       // TODO: should this be set in the aggregation state?
03        Locale locale = LocaleUtils.toLocale(dialog.getConfigValue("locale", null));
04        boolean isFallbackLanguage = i18nContentSupport.getFallbackLocale().equals(locale);
05
06        if (isEnabled() && i18nContentSupport.isEnabled() && locale != null ) {
07            List<DialogControlImpl> tabs = dialog.getSubs();
08            for (DialogControlImpl tab : tabs) {
09                List<DialogControlImpl> controls = tab.getSubs();
10                for (DialogControlImpl control : controls) {
11                    boolean i18n = BooleanUtil.toBoolean(control.getConfigValue("i18n"), false);
12                    if (i18n) {
13                        if(!isFallbackLanguage){
14                            String newName = control.getName() + "_" + locale.toString();
15                            control.setName(newName);
16                        }
17                        String translatedLabel = control.getMessage(control.getLabel());
18                        control.setLabel(translatedLabel + " (" + locale.toString() + ")");
19                    }
20                }
21            }
22        }
23    }

Comment by Philipp Bärfuss [ 10/May/11 ]

@Ondrej: can you verify that?

Comment by Samuel Schmitt [ 16/Apr/12 ]

I found this issue 1 year ago on 4.4, and the problem is still here on 4.5.x.

It's really easy to reproduce:

  • Create a new site definition (that does not extend the default one !!)
  • In the node i18n change the defaultLocale and fallbackLocale to DE (or anything else that is not EN)

Then create some content in German (DE), your i18n content will be suffixed by "_de". But as it's my default language the content shouldnt be suffixed.

If you change in the default site definition the default and fallback local from EN to DE, then it works correctly.

For me it's definitively a bug, because my site definition is not bound to the default site definition.

So either it's a bug or you must update the documentation and explain that in the case of i18n you have to change the default site def if you want to use another default locale.

Comment by Eric Hechinger [ 10/May/12 ]

Analyzes done by Richard Unger are correct.
The issue came in fact from the ETKSiteManager.getAssignedSite(String domain, String uri).
This method uses the ETKModule.getSiteCache() to retrieve the site associated to the domain+uri of the dialog.
In this cache all dialog uri are mapped to the default site --> wrong.
Now, for dialog uri, Site ETKSiteManager.getAssignedSite(Node content) is used.
From the request we get the workspace name and the content path related to the dialog.
With these two information we retrieve the content Node related to the dialog, and from this Node, retrieve the related Site.

Comment by Eric Hechinger [ 10/May/12 ]

Fixed for 4.5.3.

Comment by Ondrej Chytil [ 16/May/12 ]

All dialogs in admincentral are not working - attaching stacktrace.

Comment by Eric Hechinger [ 16/May/12 ]

Oups... I restricted the search site with node only for the Website repository. In case of Dialog for the Admin interface, do not search a site definition for the admin interface.

Comment by Jan Haderka [ 23/May/12 ]

Don't fix issues by adding "fixme" to the code. Fix it properly. If there is a change required in main project, create issue for that change in main project, fix it there and then fix this issue properly.

Comment by Milan Divilek [ 29/May/12 ]

All dialogs from page-editor for website which don't have site definitions return HTTP Status 500
Step to reproduce:
1. In admincentral create new home website
2. Then open this website
3. Try open any dialog - HTTP status 500 - look stacktrace in attachment

But when you create new site definition with mapping for handlePrefix for this site then dialogs are shown correctly.

Comment by Eric Hechinger [ 29/May/12 ]

Add an if statment in ETKSiteManager.getAssignedSite(Node content){
to handle the fact that a site may not have a default site definition.

Comment by Will Scheidegger [ 28/Aug/12 ]

Please fix this for 4.4.x too! Thanks!

Generated at Mon Feb 12 05:27:39 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.