Overview
Currently, you cannot make translations through the UI until a number of issues are resolved
But we met with @lauriii and we generally know a couple of things
- For MVP: Translation will not happen in the Canvas UI. It will happen in content_translation/config_translation and/or TMGMT and its sub-modules
- We will need a method to preview non-default languages in the UI
Proposed resolution
What we will need
- A language dropdown

This design is from Asymmetric translation but the dropdown should be similarIt should show all languages on the site. These can be found here admin/config/regional/language. It should not just show languages the current entity is translated for. This is for 2 reasons. 1) Regions do not have their own URL, so you need to see regions in a different language even if no page/template is in that language. 2) A page/template can look different in another language even if it falls back to the default language because the entities it references might have translations, and templates will display field values in that language even if there is no template translation
The dropdown should appear and be enabled when either config_translation or content_translation is enabled.
This is true for Pages and ContentTemplates. For Pages, even though they are content entities, if only config_translation is on, regions could be translated. For ContentTemplates, even though they are config entities, even if only content_translation is enabled, the preview nodes could be translated.
- Once the user selects a different language, it should open a view similar to the view you see when you click "Preview". We can't use the current Preview mode because that just displays the current layout HTML. (I, tedbow, am not a front end developer, so I am not sure how we should do this)
-
The previewing of the non-default language can use the existing layout endpoint at
/canvas/api/v0/layout/{entity_type}/{entity}but with a language prefixfr/canvas/api/v0/layout/{entity_type}/{entity}\Drupal\Tests\canvas\Functional\TranslationTest::testTranslationproves that you can request a translation of the layout; see the assertionsself::assertSame($expected_original_label, $get_name_in_api_response('/canvas/api/v0/layout/node/1')); self::assertSame("Drupal, c'est magnifique !", $get_name_in_api_response('/fr/canvas/api/v0/layout/node/1'));
Currently we can't make translations via the UI. To get around this:
- For manual testing, update
canvas_dev_translationto create translations on install for testing.Create an entity and translation for each type: Page, Template, Content Template.
See \Drupal\Tests\canvas\Functional\TranslationTest::createCanvasNodeWithTranslation; this creates a node, but creating a Page should be the same.
For
ContentTemplate's we don't have an example in 1.x, so you will have to look at this https://git.drupalcode.org/project/canvas/-/merge_requests/898?file=8cd1...which is this MR https://git.drupalcode.org/project/canvas/-/merge_requests/898
We don't have an example for PageRegion, but it should be similar to
ContentTemplate(if this is a blocker, just skip PageRegion for now to get the issue moving) -
The minimum
canvas_dev_translationshould create:- A canvas page with a header component and different text for the header in a translation
- A PageRegion with a header component and different text for the header in the config language override
- A ContentTemplate with a header component and different text for the header in the config language override
and a header component that is linked to the node titleThere are a couple of other scenarios we can't test, but we should put @todo's to test later
#3552924: When rendering content templates' linked prop sources (entity fields, host entity URLs …), load the relevant translation instead of the default
#3583379: Referenced entities not resolved to current language translation in Evaluator
(note to self, check if these issues are actually duplicates)
- A playwright test can enable
canvas_dev_translationand test with the entities and the translations it makes.
User interface changes
When viewing a page/template and either config_translation or content translation is enabled and canvas_dev_translation is enabled:
- There should be a new dropdown to select a language to preview the entity in another language. It should show all languages enabled on the site; see /admin/config/regional/language
- When a language is selected, the user is shown the current layout in a modal similar to if they clicked "Preview" in the toolbar now
| Comment | File | Size | Author |
|---|---|---|---|
| language-dropdown.png | 138.76 KB | tedbow |
Issue fork canvas-3585452
Show commands
Start within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
Comments
Comment #2
tedbowComment #3
tedbowAssign to myself. I will make the changes needed to
canvas_dev_translationto create the entities and translations for testingComment #5
tedbowI updated canvas_dev_translation to create page, region and template with a translation
See the MR for instructions, you need to do before installing canvas_dev_translation https://git.drupalcode.org/project/canvas/-/merge_requests/935
This should be enough for now start on the front
See the \Drupal\Tests\canvas\Functional\TranslationTest::testCanvasDevTranslationLayoutApi for how this works.
Basically you should be able to request
/fr/canvas/api/v0/layout/canvas_page/PAGE_IDto get the french translation. It comes back in the same format as the untranslated layout GET request. There is an `html` in the response which should be usable for the previewNote: For the playwright test we may want to create a recipe instead of using
canvas_dev_translation_installComment #7
tedbowJust changing status to show it is in progress
Comment #8
tedbowSaw a demo, looks great!
Adding Needs tests for e2e tests. One thing I was wondering, since we altering ui/src/features/pagePreview/PagePreview.tsx(which makes sense), does the existing preview mode actually have e2e test coverage. Because there is always the risk we could be altering the current functionality. I have no reason to think we are just trying to be careful