[MGNLSTK-614] Freemarker ${i18n[..]} expressions shouldn't result in freemarker exception if "i18nBasename" property is not set for paragraph Created: 26/Mar/10  Updated: 30/Apr/15  Resolved: 30/Apr/15

Status: Closed
Project: Magnolia Standard Templating Kit (closed)
Component/s: None
Affects Version/s: 1.2.1
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: Vivian Steller Assignee: Philipp Bärfuss
Resolution: Outdated Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Template:
Acceptance criteria:
Empty
Date of First Response:

 Description   

Calling ${i18n[....]} in a template that does not define i18nBasename throws a freemarker exception "Expression i18n is undefined".

I suggest that the i18n array should always be defined in freemarker, no matter what the i18nBasename is. Having no i18nBasename property in the paragraph definition should IMO be handled as if the i18n messages file isn't available and should not result in an exception.

So, this is most probably not a STK issue yet, however, I think it would make sense to integrate something like ${i18n(...)} (method call, not array) into STK to achieve the desired behavior.



 Comments   
Comment by Christian Ringele [ 26/Mar/10 ]

I think the i18nBasename property should be definable on the site definition as a default value.
So paragraphs&template not defining the value explicit, would inherit it from the site configuration.

Comment by Magnolia International [ 26/Mar/10 ]

Calling ${i18n[....]} in a template that does not define i18nBasename throws a freemarker exception "Expression i18n is undefined".
I suggest that the i18n array should always be defined in freemarker, no matter what the i18nBasename is.

Makes sense, especially since we always a fallback to the default message bundle anyway (i think)

Having no i18nBasename property in the paragraph definition should IMO be handled as if the i18n messages file isn't available and should not result in an exception.

It should probably have the same behavior as info.magnolia.cms.i18n.EmptyMessages.

So, this is most probably not a STK issue yet, however, I think it would make sense to integrate something like ${i18n(...)} (method call, not array) into STK to achieve the desired behavior.

That would just be confusing.

Christian Ringele added a comment - 26/Mar/10 12:00 PM
I think the i18nBasename property should be definable on the site definition as a default value.
So paragraphs&template not defining the value explicit, would inherit it from the site configuration.

I'm not sure about this: you'll want to redefine that property on your custom site to override the messages such as "read on" etc; BUT the same i18nBasename is also used to translate the paragraphs and templates names/definitions.
I like the idea, but we'd need some clarifications as to what translations go where. Perhaps the few translations such as "read on" should not even be in the paragraph definition's translations. OR, the site-i18nBasename could have priority, and fall back to the paragraph's for keys that are not defined in the site's i18n bundle.

Generated at Mon Feb 12 07:28:44 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.