[MAGNOLIA-4580] Areas ignore their i18nBasename Created: 12/Oct/12  Updated: 26/Jul/13  Resolved: 19/Jul/13

Status: Closed
Project: Magnolia
Component/s: templating
Affects Version/s: 4.5.4, 5.0
Fix Version/s: 4.5.10, 5.0.2, 5.1

Type: Bug Priority: Minor
Reporter: Andreas Antener Assignee: Roman Kovařík
Resolution: Fixed Votes: 0
Labels: i18n
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: PNG File Screen Shot 2012-10-12 at 12.06.24.png     File patch.diff    
Template:
Patch included:
Yes
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
Testcase included:
Yes

 Description   

If we add a new area to the prototype with custom i18nBasename, the title will not be loaded on STK pages. Instead it shows the label.
See attached screenshot with area configuration. (the area will be enabled on certain pages, eg. stkArticle)

The same problem occurs if I want to add an area from STK to a custom component. E.g.:

  • myTeaser
    • templateScript: /module/components/myTeaser.ftl
    • i18nBasename: com.module.messages
    • title: myTeaser.title
    • areas
      • linkList
        • i18nBasename: info.magnolia.module.templatingkit.messages (manually added)
        • title: areas.components.linkList.title

Now the title from the STK area will not show.



 Comments   
Comment by Andreas Antener [ 08/Feb/13 ]

To clarify this issue:
The problem is that the title property of the area will not be looked up in the message bundle specified by the i18nBasename from the area itself.
Instead, it will be resolved with the message bundle specified by its parent (the parent area or template definition).

I propose a change in info.magnolia.templating.elements.AreaElement. See attached patch (includes a test case).
The patched version will look for an i18nBasename on the area definition first, and it will fall back to the parent definition if there is none declared on the area.

I admit that this is a minor issue, but if the labels don't get resolved it always looks like there's something broken on the front end.
Also I believe that the new behaviour would be more consistent with how i18nBasename and label/description properties work on components.

Unfortunately I'm not quite sure how big the risk of breaking existing configurations would be.

Regards,
Andy

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