[MGNLUI-3128] FormBuilder: defaultLocale in dialogs is always taken from the "default" site definiton Created: 28/Aug/14  Updated: 05/Dec/14  Resolved: 30/Sep/14

Status: Closed
Project: Magnolia UI
Component/s: dialogs, forms, framework
Affects Version/s: 5.3.2
Fix Version/s: 5.3.4

Type: Bug Priority: Major
Reporter: Christian Ringele Assignee: Philip Mundt
Resolution: Fixed Votes: 1
Labels: support
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: JPEG File fallbackLocal.jpg    
Issue Links:
Relates
relates to MAGNOLIA-5940 AbstractI18nContentSupport wrongly de... Closed
causality
relation
is related to MGNLUI-3068 Add method getDefaultLocale(Node node... Closed
is related to MAGNOLIA-5931 AbstractI18nContentSupport.getPropert... Closed
is related to MULTISITE-30 Issue a warning if a site definition ... Closed
supersession
supersedes MULTISITE-22 Edit mode locale selector is not popu... Closed
supersedes MGNLEE-200 DefaultLocale and fallbackLocale dont... Closed
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   

When opening an edit dialog in page app, defaultLocale is taken from the default site and not from node-based I18NAuthoringSupport.

Additionally, the DefaultI18NAuthoringSupport.i18nize(...) method wrongly uses the fallbackLocale to add a suffix to i18nizable properties. It should instead use the defaultLocale.

Possible solution:
  • Add getDefaultLocale(Node node) and getI18nContentSupport(Node node) methods for DefaultI18nAuthoringSupport.
    • Used Extended18NAuthoringSupport as workaround (we don't want to change interface in minor version).
  • Use introspection to check if getDefaultLocale(Node node) method exists and invoke it if it is. Remove this once MGNLUI-3068 is done.

Both solutions have in common:

  • Add getRelatedFormItem() to BasicTranformer and then using it in DefaultI18NAuthoringSupport.i18nize(...) to get node-based I18NAuthoringSupport from nodes created by FormBuilder.
Notes

The described behavior was also detected on the defaultLocale (MULTISITE-22).



 Comments   
Comment by Christian Ringele [ 28/Aug/14 ]

follow up

Comment by Evzen Fochr [ 25/Sep/14 ]

To work correctly MAGNOLIA-5931 and MULTISITE-30 are needed !

Comment by Mikaël Geljić [ 26/Sep/14 ]
  • FormBuilder should use default locale, not fallback.
  • Extract method for resolving I18nContentSupport from Item
  • Don't add interface methods quite yet (check and cast to Default* for the time being, add comment on 5.4 ticket)
  • Title / description of this ticket should be revised
Comment by Evzen Fochr [ 29/Sep/14 ]

ExtendedI18NAuthoringSupport.java is a workaround preventing circling dependency between framework and dialog.

Comment by Mikaël Geljić [ 30/Sep/14 ]

Good point, we can't cast to DefaultI18nAuthoringSupport there :# Let's see if that's the way to go.

Comment by Mikaël Geljić [ 30/Sep/14 ]

Alright, looking again at i18nization vs. forms: there are fishy things in code that have been here for months, and we'd like to prevent adding more on top.

  • First I18nContentSupport in AbstractFieldFactory is unused!!
    • Let's get rid of it and deprecate related APIs accordingly.
    • no need to set it in FormBuilder then
  • We should use I18NAuthoringSupport throughout the FormBuilder, not I18nContentSupport
    • We'd like to try to resolve node-aware #getDefaultLocale via introspection in a private method to circumvent the dependency issue
    • It does not happen in rendering so the temporary performance hit is not critical
    • We'll anyway get rid of it in 5.4
  • Remove (incorrect) handling of locale in DefaultI18NAuthoringSupport.
    • We want to resolve locale only once for the whole form (in FormBuilder?)
    • In FormBuilder we know the item so we wouldn't have to get it from the property transformer

For now we're still checking how to proceed on this one / what is reasonable to do now.

Generated at Mon Feb 12 09:03:29 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.