Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[FEATURE]: Translate Rich Text Blocks #401

Open
jsadoski-rockhall opened this issue Feb 23, 2024 · 10 comments · May be fixed by #402
Open

[FEATURE]: Translate Rich Text Blocks #401

jsadoski-rockhall opened this issue Feb 23, 2024 · 10 comments · May be fixed by #402
Labels
enhancement New feature or request

Comments

@jsadoski-rockhall
Copy link

Is your feature request related to a problem? Please describe.
When using the new Rich Text (Blocks) field, the content is not translated.

Describe the solution you'd like
Rich Text (Blocks) fields should be translated to the target locale.

Describe alternatives you've considered
For now, this field type is unusable if automated translation is required. Instead, we must continue to use Rich Text (Markdown) text fields.

Additional context
We use Deepl to translate our content. Given the structure of Blocks objects in the Strapi API, it may be difficult to send to the translation API and get back a meaningful response that respects grammar, etc.

Sorry if this issue has already been raised, but I didn't find any previous GH issues.

@jsadoski-rockhall jsadoski-rockhall added the enhancement New feature or request label Feb 23, 2024
@boardmain
Copy link

Any updates?

@sargreal
Copy link
Member

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.

@jsadoski-rockhall
Copy link
Author

@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!

@boardmain
Copy link

boardmain commented Feb 28, 2024

@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 )

@jsadoski-rockhall
Copy link
Author

@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.

@sargreal
Copy link
Member

@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.

@boardmain
Copy link

boardmain commented Feb 29, 2024

@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)
        }

sargreal added a commit that referenced this issue Mar 1, 2024
This implements basic support for the blocks format for the blocks rich text editor

fix #401
@sargreal sargreal linked a pull request Mar 1, 2024 that will close this issue
@sargreal sargreal linked a pull request Mar 1, 2024 that will close this issue
@boardmain
Copy link

thank you,
can you only merge this

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

so i can handle it in a custom provider?

@boardmain
Copy link

boardmain commented Mar 16, 2024

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 )

@kristiczk
Copy link

deepljsonb

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

sargreal added a commit that referenced this issue Aug 22, 2024
This implements basic support for the blocks format for the blocks rich text editor

fix #401
sargreal added a commit that referenced this issue Oct 2, 2024
This implements basic support for the blocks format for the blocks rich text editor

fix #401
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
Status: In Progress
Development

Successfully merging a pull request may close this issue.

4 participants