[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: |
|
||||||||||||||||||||||||||||||||||||
| 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):
It is an idea to implement this at some stage? UPDATE: 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:
|
| Comment by Christoph Meier [ 10/Jul/15 ] |
|
I reopened this ticket, because: Now we have 2 different "i18n objects" within freemarker context. (and JSP).
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. 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 |