Increase the types of blocks Content Translation supports

[dkotter]

What problem does this address?

Currently the Content Translation experiment (introduced in #747) will only translate heading and paragraph blocks (as well as optionally the title). While this is good enough to test the feature out, ideally we support as many blocks as possible.

What is your proposed solution?

Increase block type support from only headings and paragraphs to as many Core blocks (that contain text) as we can. Worth noting some of our other experiments do already process additional blocks (see Editorial Notes as an example). So I think there's already functionality built-in that we can look to take advantage of here.

Why is this important to you?

No response

I have searched existing issues and this is not a duplicate.

• Yes

[yogeshbhutkar]

This has been on my TODO list for quite some time now. The main issue is that processable user-entered data isn’t always stored in content or value. There are several other attributes that can contain data we’d want to process. For example, accordion-heading may store its translatable title in the title attribute, several blocks use label, the Details block uses summary, and many media blocks may store text in caption.

A block can also contain multiple processable fields/attributes. The Pullquote block, for example, has both value and citation, which means, if we process this block, we'd need to consider both. With the current approach, we treat the block itself as the unit of work. That works when a block has only one processable piece of data, but ideally there could be multiple fields within the same block that's needed to be handled independently. That is, when we run translation on Pullquote, it should translate the data in both the value and the citation fields. It's similar for other experiments.

I think we should instead move toward treating an individual field or attribute as the unit of work. Ideally, we’d have a central registry that defines which fields/attributes are processable for each block, since not every block attribute should be processed. We could then build a small API layer around that registry and reuse it for any block-level processing.

We should also provide an extension point, likely through a filter/action, so third-party blocks can register their own processable fields. That would allow these experiments and any future block-level processing features to work with custom blocks as well.