[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:
relation
is related to MAGNOLIA-5344 Convenience component to translate an... Closed
is related to MAGNOLIA-5268 As a developer I can annotate objects... Closed
is related to MGNLSTK-1423 I18nize STK Closed
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)
And not the content i18n mechanism. (content i18n providing the stored content of different language )

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)
The new way would be not setting i18nBasename. This works for dialogs, but not for templates, yet.

Template-Def. requires an i18nBasename (RenderableDefinition#getI18nBasename)
(a) In the „old way“ property could have a value like info.magnolia.module.documentation.contentreusing.messages (or mgnl-i18n.documentation-reuse-content-messages) text is rendered properly.
(b) If the property is just left empty, no error occurs but the string cannot be translated and ?key? is rendered instead (3x? on each site, but jira renders just one).
(c) If the the property is removed, freemarker.core.InvalidReferenceException is thrown

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)
i18nBasename is known, MessagesWrapper is handling the i18n-stuff, but this one is using using deprecated MessagesManager

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

  • use SimpleTranslator, which is really just a crutch for cases where we can't generate a key, OR
  • write I18nKeyGenerator implementations for RenderableDefinition ... which ideally should take current site into consideration, etc etc.

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:

  • Keep the current situation for templating
  • Prioritize the "migration" the STK dialog definitions / translations to the new system. This is still outstanding (see [ ... currently searching ticket, will update when found ... ]). This will
    • Split the translation files - all dialog labels in one under /mgnl-i18n/ and the few remaining templating labels can stay under info/magnolia/templatingkit/... aka their basename.
    • Allow people like the fellow commenting on documentation to translate/customize their templating labels.
  • Update documentation to better reflect this differentiation (my gut feeling tells me it's not clear) https://documentation.magnolia-cms.com/display/DOCS/Making+a+module+translatable / https://documentation.magnolia-cms.com/display/DOCS/Language

There are also other issues to take care of in this respect:

  • The page editor buttons (add component, edit, trash, ...) are currently not translated. This is currently fine, but we ultimately do want hover/tooltips for those, and typically we'll then want them to say "edit this teaser" rather than a generic "edit this component".
  • When this happens, we'll need to think twice - if the component has an i18nBasename, things might go awry (or just confusing) with regards to generated keys vs templating label keys. (either we need to verify that the presence i18nBasename does not prevent from falling back through generated keys (if generated key is "X" and i18nBasename is "B", then look for translations in B:X then fallback to <global>:X
  • In short^2, this will mean we might need to revisit and implement some of the missing pieces of info.magnolia.i18nsystem (i.e. the tooling that helps "migrating", review the translation loader which was originally designed to keep track of where a translation came from, etc)
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)

Generated at Mon Feb 12 04:09:13 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.