### Problem/Motivation When a `PageVariant` has a config translation, the translated values never appear in any Canvas preview — even though the front end renders them correctly. Switching the editor's language dropdown, or opening the preview route with `?language=hu`, still shows the base-language text. "Translation" as shown on frontend of the site: {width=900 height=359} Lack of translation on Canvas preview of translation: {width=900 height=527} So the editor's language switcher is effectively cosmetic for these entities: the preview contradicts what the site actually serves. ### Steps to reproduce 1. Add a second language; translate any input of the page variant via config translation. 2. Verify the front end in the second language shows the translation. 3. In the Canvas editor, switch to that language (or open `/canvas/preview/{entity_type}/{id}/full?language=…`) → previews show the untranslated base. ## Canvas previews render the untranslated base tree — translation overrides must be applied when building previews **Project:** Drupal Canvas · **Component:** Editor / Preview · **Version:** 1.x-dev ### Problem/Motivation When a config entity with a component tree (e.g. the `PageVariant` a site template generates) has a config translation, the translated values never appear in any Canvas preview, even though the front end renders them correctly. Switching the editor's language dropdown — which drives the supported preview-language mechanism (`?canvas_preview_langcode=…`, redirected through the site's language negotiation) — still shows base-language text everywhere. Measured on a site with a `hu` override translating two footer components: | Surface | Shows translation? | |---|---| | Front end in `hu` | ✅ | | Editor preview of the variant itself (layout GET at the negotiated preview URL, `Content-Language: hu`) | ❌ base text | | Page chrome around a content entity preview (behind the client's `/preview/{entity_type}/{id}?language=…` route) | ❌ base footer | The editor's language switcher is therefore effectively cosmetic for these entities: the preview contradicts what the site serves. ### Architectural framing Canvas intentionally operates on **base config**. Its routes do not support language-prefixed operation, entities are (and should be) upcast untranslated, and editing must always edit the original: the client model and PATCHes read and write base data only. Translation is supposed to surface in exactly one place — **preview rendering**, driven by the explicitly requested preview language. That last step is what's missing: no preview path ever consults the translation override. ### Steps to reproduce 1. Install with a site template that creates a `PageVariant` (e.g. Haven), default language English. 2. Add a second language; translate any input of the page variant via config translation. 3. Verify the front end in that language shows the translation. 4. In the Canvas editor, switch the preview to that language (or open `/canvas/preview/{entity_type}/{id}/full?language=…`) → previews show the untranslated base. 5. Optional: make any unpublished edit so an auto-save draft exists — the chrome case then reproduces with certainty. ### Root cause 1. **The layout GET's own preview** (`ApiLayoutController::buildPreviewRenderable()`): builds the preview straight from the upcast (base) entity. The requested preview language's override is never merged in. 2. **The page chrome around content previews** `CanvasPageVariant::buildPageVariant()`: in preview prefers the entity's **auto-save draft**. Drafts live outside the config system (key/value), so a `LanguageConfigOverride` structurally cannot apply to them — with a draft present, the chrome is always base-language no matter what. The building block already exists: `ComponentTreeConfigEntityBase::getTranslatedComponentTree()` merges base — including a draft's tree — with a language's override. Both fixes are necessary and independent; each covers exactly one surface (verified by applying them one at a time): | Configuration | Variant editor preview (hu) | Content preview chrome (hu) | |---|---|---| | Controller fix only | ✅ | ❌ | | Chrome fix only | ❌ | ✅ | | Both | ✅ | ✅ | ### Proposed resolution In both places, when building a **preview** and the current language differs from the entity's langcode and a non-empty override exists for it, use `getTranslatedComponentTree()` instead of the raw tree. MR attached: two files, ~46 lines — `ApiLayoutController::buildPreviewRenderable()` plus a small `getPreviewComponentTree()` helper on `CanvasPageVariant` used by the variant and legacy-regions paths, preview mode only; `LanguageManagerInterface` added to the plugin's constructor. Live (non-preview) rendering untouched. Verified on a live site (two translated components, draft present): base-language previews unchanged; previews in `hu` show both translated strings with the base strings gone — in the variant editor and in the content-preview chrome. With the MR, preview shows up: {width=900 height=527} ### Remaining scope / notes - **No automated test in the MR yet.** The natural home is `ApiLayoutControllerGetTest`; I couldn't run it locally (its setup installs `canvas_oauth`, whose `simple_oauth` dependency my project lacks), so I'm not attaching an unverified test.