[MAGNOLIA-6181] Expose i18n functionality via context object in FreemarkerHelper Created: 23/Apr/15  Updated: 15/Apr/16  Resolved: 23/Dec/15

Status: Closed
Project: Magnolia
Component/s: freemarker
Affects Version/s: None
Fix Version/s: 5.4.4

Type: Improvement Priority: Neutral
Reporter: Edgar Vonk Assignee: Roman Kovařík
Resolution: Fixed Votes: 0
Labels: support
Remaining Estimate: 0d
Time Spent: 6.5h
Original Estimate: Not Specified

Issue Links:
Relates
causality
is causing MGNLEE-423 MAGNOLIA-6181 breaks RegistrationFilt... Closed
dependency
is depended upon by MTE-64 Revise existing MTE components Closed
duplicate
is duplicated by MAGNOLIA-6417 Add support for new I18N mechanism Closed
relation
is related to MAGNOLIA-6316 Provide templating functions to i18ni... 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)
Date of First Response:
Epic Link: deprecate old i18n
Sprint: Kromeriz 24
Story Points: 3

 Description   

The i18n FTL templating support object (an instance of info.magnolia.freemarker.MessagesWrapper) still uses the old i18n mechanism and requires the old 'i18nBasename' property and hence a separate resource bundle file from the default new location in mgnl-i18n. This is very inconvenient we only want a single resource bundle location.

@zdenek thought of the following solution (see SUPPORT-4560):


How about to add something to TemplatingFunctions for this purpose? So that you could use something like cmsfn.i18n('key') that would pass the key to the translation service and eventually also fallback to the "old" i18n way of resolving the labels if not found.

It is an idea to implement this at some stage?

UPDATE:
had already outlined the specifics in the comment from 8th of Oct.
TranslationService already has the functionality to fallback to the old basename-functionality: info.magnolia.i18nsystem.TranslationService#translate(info.magnolia.i18nsystem.LocaleProvider, java.lang.String, java.lang.String[]). It's only a matter of wiring everything nicely together to make the new i18n-mechanism available in templates, while providing fallback for basename-usages.

info.magnolia.freemarker.FreemarkerHelper#addDefaultData
info.magnolia.freemarker.MessagesWrapper

We should delegate to TranslationService in MessagesWrapper (or similar).



 Comments   
Comment by Roman Kovařík [ 07/Jul/15 ]

Reopened:

  1. Add the method also to JspTemplatingFunction.
  2. I'd expect a test like this:
    @Test
        public void testI18n() {
            // GIVEN
            when(simpleTranslator.translate("key")).thenReturn("translation");
    
            // WHEN
            String result = functions.i18n("key");
    
            // THEN
            assertThat(result, equalTo("translation"));
        }
    
Comment by Christoph Meier [ 10/Jul/15 ]

I reopened this ticket, because:

Now we have 2 different "i18n objects" within freemarker context. (and JSP).

  • Rendering context "root object" i18n relies on our "old i18n" mechanism. Something which cannot change to use new i18n API atm. (See FreemarkerHelper#prepareRendering which is using info.magnolia.freemarker.MessagesWrapper)
  • cmsfn.i18n object relies on "new i18n API" (using SimpleTranslator).

To have both i18n and cmsfn.18n parallel is weird or at least confusing. I shortly talked with Greg and he agrees that this no good idea.
in 5.4+ freemarker is split out of core, so it might be possible to use i18n stuff in there (to be verified).

At the moment i would say this ticket cannot be fixed appropriately. Edgars proposal actually works but is rather a workaround.

Comment by Jan Haderka [ 10/Jul/15 ]

Hi Edgar,

thanks for reporting the issue. We recognise the problem. However trying to provide workaround we realised there are some other deeper implications and fixes necessary to solve the core of the problem. Rather than quickly patching the code and bringing in whole new bunch of issues that we would have to carry over for the future, we will be reworking this in more complex way on the latest production version (5.4.x) and depending on the complexity of the final solution will consider back porting this to 5.3.x.

Thank you for your understanding.

Jan

Comment by Edgar Vonk [ 13/Jul/15 ]

hi had,

Clear and I understand your decision. I hope you guys will be able to get rid of the old i18n mechanism with some kind of fallback support to still use the old i18n resource bundles because otherwise everyone needs to upgrade their resource bundles. In any case the real confusion I think is the two i18n mechanisms in Magnolia and hopefully this can be fixed soon.

cheers

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