[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: |
|
||||||||||||||||||||||||||||||||
| Issue Links: |
|
||||||||||||||||||||||||||||||||
| Sub-Tasks: |
|
||||||||||||||||||||||||||||||||
| 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). Then edit the properties of a page (like the title) in the german edit mode. |
| 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:
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. Since the “demo-project” uses fallbackLocale “en”, which is also the default, everything works fine for “demo-project” i18n. 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:
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. |
| 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 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){ |
| Comment by Will Scheidegger [ 28/Aug/12 ] |
|
Please fix this for 4.4.x too! Thanks! |