[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: |
|
||||||||||||
| 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)
|
||||||||||||
| 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:
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. |