Verse: Block example should be a single string for translators to handle

[mcsf]

Context

See context for block examples:

• Design issue Inserter Panel: Need block previews for each block #17488
• API implementation Add the block example API and use it for inserter and switcher previews #17124
• First examples Add block examples for all core blocks #17493

Issue

Currently, the example for the Verse block is made up of distinct translatable strings:

gutenberg/packages/block-library/src/verse/index.js

Lines 24 to 33 in 59da6ed

	example: {
	attributes: {
	content: __( 'WHAT was he doing, the great god Pan,' ) + '<br>' +
	__( ' Down in the reeds by the river?' ) + '<br>' +
	__( 'Spreading ruin and scattering ban,' ) + '<br>' +
	__( 'Splashing and paddling with hoofs of a goat,' ) + '<br>' +
	__( 'And breaking the golden lilies afloat' ) + '<br>' +
	__( ' With the dragon-fly on the river.' ),
	},
	},

This harms the translating experience greatly, as becomes clear by looking up any of its verses in GlotPress (see Portuguese (Portugal) for instance):

• Translators need to find verses separately
• Translators need to make sense of them and understand the context of each string
• Translators are bound to translating each verse independently

As a consequence, translators lose the freedom to adapt rather than translate, i.e. free themselves from a verse-by-verse translation — which is a difficult to do and of low value to users of that locale — and possibly provide a comparable block example that is fitting of the locale at hand, such as a local poem.

Solutions

The motivation to keep verses separate may have come from the fact that they need to be stitched with HTML, namely the line breaks (<br>). In the broader Gutenberg codebase, this is an internalisation challenge requiring element interpolation that is tracked in #9846.

However, when dealing with block examples, we are in the unusual case of translating not UI, not code in a stricter sense, but serialised data representing user content. Thus, the example strings can in fact contain HTML elements. In fact, I'd argue that this is the most correct thing to do, as it fits the idea that we're letting content be translated.

Questions: What care should be exercised in such a scenario? Should we beware of ill-intentioned translators seeking to inject unexpected content?

/cc @swissspidy and anyone you'd like to add to the conversation

[mcsf]

However, when dealing with block examples, we are in the unusual case of translating not UI, not code in a stricter sense, but serialised data representing user content. Thus, the example strings can in fact contain HTML elements. In fact, I'd argue that this is the most correct thing to do, as it fits the idea that we're letting content be translated.

Explored in #18365.