[MAGNOLIA-8030] Improve i18n key generators to work with extends Created: 20/Jul/15 Updated: 11/Mar/21 |
|
| Status: | Accepted |
| Project: | Magnolia |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Improvement | Priority: | Neutral |
| Reporter: | Christopher Zimmermann | Assignee: | Unassigned |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| 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: | Enhancement of i18n | ||||||||
| Story Points: | 5 | ||||||||
| Description |
|
The new I18N system does not play nice with the JCR extends mechanism because an extended definition has a new name and will therefore generate translation keys with this new name. So if I extend an App - all of the items with keys that depended on that apps name - will now be untranslated. There is a POC for dialog key generator in linked PR. We'd need the similar change in most of the generators. It's kind of effort to do this everywhere. The question is if it's worth the effort or we can solve most of the problems by using of less specific keys. (e.g. tabMain.fieldNam,label instead of dialogWhichOtherDialogsExtendsFrom.tabMain.fieldNam.label) |
| Comments |
| Comment by Christopher Zimmermann [ 08/Sep/15 ] |
|
Duplicate of |
| Comment by Christopher Zimmermann [ 20/Jan/16 ] |
|
Will the proposed POC solution also help in the case of yaml extends/decoration? |