Overview
For symmetric translations it should be possible for a content entity translation to only store the string translatable inputs and rely on the default language translation for other inputs
for instance looking at tests/modules/canvas_test_sdc/components/my-hero/my-hero.component.yml
heading:
type: string
title: Heading
description: The main heading of the hero
examples:
- There goes my hero
- Submit now
subheading:
type: string
title: Sub-heading
description: 'See the <a href="https://www.example.com/icons">icon library</a> for icons.'
examples:
- Watch him as he goes!
cta1:
type: string
title: CTA 1 text
examples:
- View
# ℹ️ For an example of a CTA that supports only absolute URLs, see the my-cta SDC.
cta1href:
type: string
format: uri-reference
title: CTA 1 link
examples:
- https://example.com
- /node/1
cta2:
type: string
title: CTA 2 text
examples:
- Click
# @see \Drupal\Core\Template\ComponentsTwigExtension::mergeAdditionalRenderContext()
attributes:
type: Drupal\Core\Template\Attribute
name: Attributes
title: Attributes
The cta1href and attributes properties should not be translatable.
But if you don't store the cta1href property with the translation you will get the error like
LogicException: inputs.208452de-10d6-4fb8-89a1-10e340b3744c.cta1href: The property cta1href is required.
and
Drupal\Core\Entity\EntityStorageException: inputs.208452de-10d6-4fb8-89a1-10e340b3744c.cta1href: The property cta1href is required.
#3582478: Symmetrically translatable config-defined component trees, STEP 2: change config schema type for `inputs` to allow translating via core's Config Translation UI deals with similar problem but for config entities that implement \Drupal\canvas\Entity\ComponentTreeConfigEntityBase
There are other problems with making these properties separate elements in forms provided by content_translation and tmgmt_content but this issue only deals with storage and programmatically saving
Proposed resolution
As start update \Drupal\Tests\canvas\Functional\TranslationTest::createCanvasNodeWithTranslation to unset cta1href and attributes in the translation. This will result in the errors above.
Figure out how to solve this. Probably this will mean updating validators and maybe \Drupal\canvas\Plugin\Field\FieldType\ComponentTreeItem, maybe getInputs and getInput
It probably makes sense to look at how #3582478: Symmetrically translatable config-defined component trees, STEP 2: change config schema type for `inputs` to allow translating via core's Config Translation UI is solving this for config.
Specifically in config/schema/canvas.schema.yml it has
inputs:
type: mapping
class: '\Drupal\canvas\Config\Schema\ComponentSpecificInputs'
label: 'Input values for each component in the component tree'
ComponentSpecificInputs looks at the component source inputs to determine which ones are translatable. Eventually we will probably want to API to get the translatable properties for a component source but for now we can probably copy some of that logic.
User interface changes
| Comment | File | Size | Author |
|---|---|---|---|
| #10 | tmgmt_content_component_inputs.png | 128.63 KB | tedbow |
Issue fork canvas-3583684
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 #3
tedbowComment #4
tedbowComment #5
tedbowComment #6
wim leersComment #7
wim leersI just realized I thought about something related a ~year ago. See the bit in #3520449: [META] Production-ready data storage
Comment #8
tedbowstill very much a rough sketch of idea. not ready for review
Comment #9
wim leersAs described in point 6 of the issue's proposed resolution as of #3582478-30: Symmetrically translatable config-defined component trees, STEP 2: change config schema type for `inputs` to allow translating via core's Config Translation UI, I think that issue should aim to provide a centralized way for both content- and config-defined component trees to determine which of the N explicit inputs of a given component instance are actually translatable.
Otherwise, we'd end up repeating the same complex logic in 2 places.
Comment #10
tedbowSome more rough changes but just want to confirm that new work @wim-leers has done in #3582478: Symmetrically translatable config-defined component trees, STEP 2: change config schema type for `inputs` to allow translating via core's Config Translation UI will work with content entities.
Good news I think it will. Right now I just have non-translatable props being stripped on saving \Drupal\canvas\Plugin\Field\FieldType\ComponentTreeItem::preSave
Also initial work on integrating with tmgmt_content

This shows the tests/modules/canvas_test_sdc/components/my-cta/my-cta.component.yml and it does not display the "target" prop which is an enum and not transable. I processed the job in tmgmt and it does create a translation at /fr/page/4. In the default translation in canvas the target for the CTA link was the same window. I then republished the default translation with the target for the CTA link as a new window. Reloading the /fr/page/4
🎉
😭It then somehow loses the translation when Publish again with a new component added. Have not looked into this.
I did not look into using content_translation directly because that relies on the entity forms and field widgets. But can explore that next to confirm that
Comment #11
wim leers#10: thanks for that update, that's great to read (and see 🤩)!
The fact that it was able to save it the first time in TMGMT is highly encouraging. I bet there's some form state shenanigans that get in the way.
I don't think we can do that, because
\Drupal\canvas\Plugin\Field\FieldType\ComponentTreeItemdoes not (anymore!) have adefault_widget(🪦TwoTerribleTextAreasWidget, removed in #3467972: Unable to save node article form — remove obsolete TwoTerribleTextAreasWidget + fix duplicate `XB:image` SDC).BTW, this also means you're effectively doing #3582558: [PP-2] WIP: Experiment to expose config-defined component instance inputs to TMGMT — precursor to Canvas-native translation UX as part of this already, I think.
Or perhaps only the content-defined component trees?Confirmed, makes sense. Great start, left some suggestions in the review.I think this should get test coverage that is largely a duplicate of
\Drupal\Tests\canvas\Functional\TranslationTest::testContentTemplateConfigTranslationUi(), but then for content translation and for the CanvasPageentity type.Comment #12
wim leersFYI #3586342: Symmetrically translatable component trees, STEP 1: introduce `ComponentInstanceInputsConfigSchemaGeneratorInterface` has been lifted out, and is now the sole blocker to this MR!
Comment #13
wim leersThis is now also blocked on #3586490: Introduce `ComponentSourceInterface::getLabelForExplicitInput()`.
Comment #14
wim leers#3586342: Symmetrically translatable component trees, STEP 1: introduce `ComponentInstanceInputsConfigSchemaGeneratorInterface` is in :)
Comment #15
wim leersInitial MR up for #3586490 — feel free to finish it, EOD here.
Comment #16
wim leers#3586490 is a tiny, trivial MR. No need to mark this postponed for that.
Comment #17
tedbow