[MAGNOLIA-5876] Freemarker templates and jsp are not aware of new i18n mechanism Created: 06/Aug/14 Updated: 16/Jun/16 Resolved: 25/Aug/14 |
|
| Status: | Closed |
| Project: | Magnolia |
| Component/s: | core |
| Affects Version/s: | 5.0 |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Major |
| Reporter: | Federico Grilli | Assignee: | Federico Grilli |
| Resolution: | Won't Fix | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||||||
| 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 |
|
As reported by a user on our docu website https://documentation.magnolia-cms.com/display/DOCS/Language?focusedCommentId=86843439#comment-86843439 It turns out that this functionality still relies on the old i18n mechanism (see info.magnolia.freemarker.FreemarkerHelper.addDefaultData() for instance). We should add support for the new i18n mechanism both to ftl and jsps and deprecate the old one based on the i18n base name. |
| Comments |
| Comment by Christoph Meier [ 08/Aug/14 ] |
|
Documentaion has been updated to inform about this "issue" (see https://documentation.magnolia-cms.com/display/DOCS/Making+a+module+translatable) |
| Comment by Christian Ringele [ 13/Aug/14 ] |
|
So here is meant the usage of the ${i18n['key.in.bundle']}
object right? (system i18n resolving message bundles) |
| Comment by Federico Grilli [ 13/Aug/14 ] |
|
@Christian right. |
| Comment by Christoph Meier [ 14/Aug/14 ] |
|
It looks like users expect that new i18n can be used in templates, too. (See http://goo.gl/G2Dav9) Template-Def. requires an i18nBasename (RenderableDefinition#getI18nBasename) I think some users expect here that they can skip i18nBasename (c) in order to use their bundles in ./mgnl-i18n/ Freemarker-situation: FreemarkerHelper#addDefaultData is doing if (i18nBasename != null) { data.put("i18n", new MessagesWrapper(i18nBasename, locale)); }// no else here so, if i18nBasename is not set, that’s it, finito (ending up with exception) To enable the new i18n-way, we should use SimpleTranslator which is part of „magnolia-i18n“ module, but both FreemarkerHelper and MessagesWrapper are part of the „magnolia-core“ module … so the dependency-situation prevents using SimpleTranslator in FreemarkerHelper or MessagesWrapper. |
| Comment by Magnolia International [ 21/Aug/14 ] |
|
IMO, templating is not currently well suited for using the info.magnolia.i18nsystem features. We would need to either
These are labels that are in essence very different from those handled by info.magnolia.i18nsystem: they are meant to be read in website pages by visitors in their "navigation language", as opposed to those read in AdminInterface by authors (in their profile languages, which isn't necessarily the language of the site they're authoring) Whether we use the old or new system, the problem with template translations, which was very apparent with STK, is that if one wants to customize the former kind of label (e.g "Read on...", "type search item here" etc - let's call them "templating labels"), they were relying on the i18nBasename of the currently rendered template definition. Which in turn was also used to describe labels of the edit/new/etc buttons for the corresponding template. As a result, we ended up putting all dialog, template-button and templating labels in the same file, which made difficult to customize just the templating labels, since you had to change the basename of the definition, and thus bring along all other dialog/template-button translations. In short, I'd suggest the following:
There are also other issues to take care of in this respect:
|
| Comment by Federico Grilli [ 25/Aug/14 ] |
|
Let's do as Greg proposed. I created a follow-up story concerning "i18nize" STK. Documentation should also be improved regarding the difference between i18n keys for templates vs author-side keys (e.g. dialogs) |