[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. |
| Comment by Magnolia International [ 26/Mar/10 ] |
Makes sense, especially since we always a fallback to the default message bundle anyway (i think)
It should probably have the same behavior as info.magnolia.cms.i18n.EmptyMessages.
That would just be confusing.
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. |