-
Bug
-
Resolution: Fixed
-
Major
-
5.3.2
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-3068is 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).
- is related to
-
MGNLUI-3068 Add method getDefaultLocale(Node node) to interface I18NAuthoringSupport
- Closed
-
MAGNOLIA-5931 AbstractI18nContentSupport.getProperty not returning right default value based on default locale
- Closed
-
MULTISITE-30 Issue a warning if a site definition doesn't specify a defaultLocale
- Closed
- relates to
-
MAGNOLIA-5940 AbstractI18nContentSupport wrongly determines locale if fallbackLocale and defaultLocale differ
- Closed
- supersedes
-
MULTISITE-22 Edit mode locale selector is not populated outside non-default site definition
- Closed
-
MGNLEE-200 DefaultLocale and fallbackLocale dont behave as expected when creating a new Site definition
- Closed