[MAGNOLIA-5562] I18n keys cannot be resolved if the app is extended Created: 18/Dec/13  Updated: 04/Mar/19

Status: Open
Project: Magnolia
Component/s: i18n
Affects Version/s: 5.2
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: Jan Schulte Assignee: Unassigned
Resolution: Unresolved Votes: 2
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Community edition on Tomcat


Attachments: PNG File Screen Shot 2013-12-18 at 11.07.05.png    
Issue Links:
relation
is related to MGNLUI-2614 Improve action buttons so that even i... Closed
is related to MGNLUI-2589 Provide generic keys for add, edit, a... 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)
Release notes required:
Yes
Date of First Response:

 Description   

For example (see screenshot): If the pages app gets extended in a different module then I18n errors are displayed in the pages app action bar.

The same thing happens if you extend an app in the same module. Since the mechanism looks for appId.whatever.key, the key path changes to something that does not exist (yet). But extension should take care of this and wrap it to find the correct labels.



 Comments   
Comment by Federico Grilli [ 15/Jan/14 ]

I tried to reproduce the issue and that's what I did and my conclusions:

  • extended Pages app under /modules/ui-admincentral/apps/fooApp
  • opening the fooApp there actually are unresolved keys but that is normal, meaning that they are specific to the app and the i18n system could not fallback to anything generic.
  • such keys can be seen by setting info.magnolia.i18nsystem.TranslationServiceImpl to DEBUG level (even though here admittedly I had to clean the output a bit because it's not that terse)
    2014-01-15 18:47:06,103 DEBUG info.magnolia.i18nsystem.TranslationServiceImpl   : No translation found for any of [fooApp.browser.actionbar.sections.pageDeleteActions.label, fooApp.browser.actionbar.sections.pageDeleteActions] with locale en 
    2014-01-15 18:47:06,105 DEBUG info.magnolia.i18nsystem.TranslationServiceImpl   : No translation found for any of [fooApp.browser.actions.add.label, fooApp.browser.actions.add, actions.add.label, actions.add] with locale en 
    2014-01-15 18:47:06,107 DEBUG info.magnolia.i18nsystem.TranslationServiceImpl   : No translation found for any of [fooApp.browser.actions.preview.label, fooApp.browser.actions.preview, actions.preview.label, actions.preview] with locale en 
    2014-01-15 18:47:06,108 DEBUG info.magnolia.i18nsystem.TranslationServiceImpl   : No translation found for any of [fooApp.browser.actions.edit.label, fooApp.browser.actions.edit, actions.edit.label, actions.edit] with locale en 
    2014-01-15 18:47:06,109 DEBUG info.magnolia.i18nsystem.TranslationServiceImpl   : No translation found for any of [fooApp.browser.actions.editPageName.label, fooApp.browser.actions.editPageName, actions.editPageName.label, actions.editPageName] with locale en 
    2014-01-15 18:47:06,111 DEBUG info.magnolia.i18nsystem.TranslationServiceImpl   : No translation found for any of [fooApp.browser.actions.editTemplate.label, fooApp.browser.actions.editTemplate, actions.editTemplate.label, actions.editTemplate] with locale en 
    2014-01-15 18:47:06,112 DEBUG info.magnolia.i18nsystem.TranslationServiceImpl   : No translation found for any of [fooApp.browser.actions.activateDeletion.label, fooApp.browser.actions.activateDeletion, actions.activateDeletion.label, actions.activateDeletion] with locale en 
    2014-01-15 18:47:06,124 DEBUG info.magnolia.i18nsystem.TranslationServiceImpl   : No translation found for any of [fooApp.browser.actionbar.sections.pageActions.label, fooApp.browser.actionbar.sections.pageActions] with locale en 
    2014-01-15 18:47:06,159 DEBUG info.magnolia.i18nsystem.TranslationServiceImpl   : No translation found for any of [fooApp.browser.label, fooApp.browser, fooApp.app.label, fooApp.app] with locale en 
    

    Some of them actually do not display in the UI as it usually happens with missing keys and the reason is that they are too long and end up being hidden (here there's certainly room for improvement).

  • to sum it up, this behaviour is perfectly fine and what one needs to do is simply add the missing specific keys to the extended app i18n properties file.

I could agree though that add, edit, activateDeletion and preview actions should have a default fallback translation, possibly in the framework module as that contains most of such generic keys.

Comment by Christopher Zimmermann [ 21/Jan/14 ]

Federico is correct that this is "by design". We discussed it a bit and started reasoning that it could be possible for the key generators to access the app definition and detect if the app was extended and if so to add keys for the extended app.

Im re-opening and changing this to an improvement. As this is something that a user would expect would work and would be very annoyed when it did not. Its also cumbersome when it does not work because user would have to create a bunch of duplicate keys.

Covering all extends options (using extends on other nodes besides the app) in a clean way might be possible but would be even additional work. My opinion is that extending the app is the most likely usecase.

Comment by Antti Hietala [ 03/Feb/14 ]

Extending an app was also my use case when I noticed this issue. Example: extend websiteJcrBrowser to view a different workspace. All labels are missing. Asking the user to create a message bundle for the new app seems unnecessary when the websiteJcrBrowser labels would be fine.

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