Summary
M2A column-display templates currently resolve a field on the M2A target collection (e.g. {{item:service.name}}), but not a deeper relation stored inside that target — in particular a translations relation. This tracks allowing templates to resolve deep relational paths, including nested translations, e.g. {{item:service.translations.label}}.
Use case
A common setup stores the user-facing label of an M2A target in a translations relation (one row per language) rather than a plain field. To show it in the table, the template needs to reach <m2a-field>.item:<collection>.translations.<field> (a third level) and pick the row for the right language. Today only the second level resolves; the nested translation renders blank.
Desired behavior
- Deep paths resolve through the M2A target: M2O chains, files, and
translations relations, to arbitrary depth.
- Translations pick the correct language, using the language field defined by the relation (not a hardcoded
languages_code).
- Language selection: an optional
:lang suffix on the token (…translations.label:de-DE) selects the language; without it the current user's language is used, falling back to the first available row.
- No regression to existing M2A templates (
{{collection}}, {{item:col.field}}, M2O chains, parent/junction fields).
- The native field picker can build these tokens (drilling into the target's relations).
Notes
- Resolution should be generic / schema-driven — interpret each hop via the relations store, not per-level special-casing.
- Out of scope: collapsing a deep to-many (O2M) relation into a single cell (no sensible single-value representation).
Acceptance criteria
Follow-up to the M2A display work in #60.
Summary
M2A column-display templates currently resolve a field on the M2A target collection (e.g.
{{item:service.name}}), but not a deeper relation stored inside that target — in particular atranslationsrelation. This tracks allowing templates to resolve deep relational paths, including nested translations, e.g.{{item:service.translations.label}}.Use case
A common setup stores the user-facing label of an M2A target in a
translationsrelation (one row per language) rather than a plain field. To show it in the table, the template needs to reach<m2a-field>.item:<collection>.translations.<field>(a third level) and pick the row for the right language. Today only the second level resolves; the nested translation renders blank.Desired behavior
translationsrelations, to arbitrary depth.languages_code).:langsuffix on the token (…translations.label:de-DE) selects the language; without it the current user's language is used, falling back to the first available row.{{collection}},{{item:col.field}}, M2O chains, parent/junction fields).Notes
Acceptance criteria
{{item:<collection>.translations.<field>}}renders the translated value in the selected/user language.:langsuffix overrides; no suffix → current user language → first-row fallback.Follow-up to the M2A display work in #60.