Any updates?

Hi @jsadoski-rockhall and @boardmain,

Thank you for your interest in this plugin and the feature proposal!

This is definitely an important feature that should be implemented in this plugin. However currently, we as maintainers have more pressing issues on the internal side and are also working voluntarily. If you require this feature, we would be very happy if you would try to implement it yourself and create a pull request. We will give you feedback on problems you may encounter.

From my understanding, the easiest way to implement this feature would be to create a rendering from the blocks syntax to html or xml, then translate that on the provider, and then convert it back to the blocks syntax.
There already exists an html renderer for the blocks syntax, so that may be used and only the translation back to the blocks syntax is required.

An issue that may definitely arise is that the rendering to html is (at least in the referenced html renderer) a lossy conversion, as not all properties are used in the html. I am not quite sure how this can be handled yet.

Another problem may arise when the document is too large to be translated in one request. Currently, there is also no good handling for splitting html documents, but this problem should definitely considered.

@sargreal Thank you for the update. Sending HTML to Deepl certainly seems like a good idea, even given the limitations.

I won't have any time to work on this anytime soon, but if it's still open in a couple of weeks, I may take a look. Thank you Strapi team for all you do, especially the volunteers!

@sargreal
hi im doing some test
adding a custom provider ( deepl modified )

but if i try to add for example to the strapi-plugin-translate configurator inside plugins.js

translatedFieldTypes: [
'string',
{ type: 'blocks', format: 'jsonb' },
{ type: 'text', format: 'plain' },
{ type: 'richtext', format: 'markdown' },
'component',
'dynamiczone',
],

it is ignored by the plugin and i can't Handle this type in the custom provider
it is ignored into getTranslateFields

in the "getFieldTypeConfig(type) function"
when it look for the block type it never continue

function getFieldTypeConfig(type) {
  const { translatedFieldTypes } = strapi.config.get('plugin.translate')

	console.log('TYPE: ->', type);
	console.log(translatedFieldTypes);
  return translatedFieldTypes.find((t) => t === type || t.type === type)
}

i see:

TYPE: -> blocks
[
  { type: 'string', format: 'plain' },
  { type: 'text', format: 'plain' },
  { type: 'richtext', format: 'markdown' },
  'component',
  'dynamiczone'
]

is like the translatedFieldTypes in the config is ignored, but the default is taken

can you help to modify the response of strapi.config.get('plugin.translate') ? if it isn't handled by the plugins.js config gile

i'm trying to handle it exactly like markdown, ( jsonb-> html -> translate -> html -> jsonb )

@boardmain I think that was the idea behind @sargreal's suggestion. Deepl can handle HTML input, so the content would need to be translated to HTML first and then sent to Deepl. Of course, then, I guess it would need to be translated back into Blocks in order to be saved. I'm sure that would introduce all manner of edge cases.

This feature may be stretching the limits of automated translation while preserving formatting. Markdown may be the ultimate solution, since Deepl handles it natively.

@boardmain

  translatedFieldTypes: [
    'string',
    { type: 'blocks', format: 'jsonb' },
    { type: 'text', format: 'plain' },
    { type: 'richtext', format: 'markdown' },
    'component',
    'dynamiczone',
  ],

So first of all, there seems to be something wrong with your setup, since I get an expected Error Error regarding translate config: unhandled format jsonb for translated field blocks when using your config. If that error isn't thrown and you have not customized the config parsing, the config you are providing is not considered at all.

I believe the format parsing should completely be implemented on the plugin side, as the providers should only provide the translation function. The execution of the format conversion is only done on the provider side, since we cannot be sure which formats are supported by a provider (although that could also be stated in the provider's declaration as well. That would be a breaking change however).

Anyways, I have tried today a little bit at implementing this feature in a rudimentary state and will open a PR in the next days where you can have a look and maybe build from there.

@sargreal yes i had an error in my plugins.js config file, now i have correctly the "Error regarding translate config"

the only question, if i can't add jsonb ( { type: 'blocks', format: 'jsonb' }, ) to the plugin config, how i can handle this new field in my plugin?

i can't handle like markdown ( in the deepl provider )

if (format === 'markdown') {
          textArray = formatService.markdownToHtml(textArray)
        }

thank you,
can you only merge this

{ type: 'richtext', format: 'markdown' },

so i can handle it in a custom provider?

until this update will be fixed, if anyone need it
i published this package
strapi-provider-translate-deepljsonb
it take all text from paragraph, translate it with deepl and writeback to object

simply install it with "npm instlal strapi-provider-translate-deepljsonb" and replace deepl with deepljsonb i the plugin.js config

it is not perfect, but for now is working

Ah you need define blocks as markdown in the plugin translate config ( view the readme of the module in npm )

deepljsonb

Hello. I have tried your solution, but nothing changes :(