[BUG]: Translating with nested components containing JSON field does not work.

[Discountrobot]

Describe the bug When you have a entity with a repeatable component, that itself contains the JSON field type, translation will fail to save - even if the component is marked as non-translatable.

To Reproduce

1. create a reusable component with a json field

2. create a entity that uses the reusable compoinent

3. fill out the original entity

4. create a new locale

5. try to translate the entity after saving.

6. observe the following error

TypeError: (i.doc || "").split is not a function
    at na.create (main.1c8cf574.js:3702:27812)
    at main.1c8cf574.js:3711:66977
    at Li (main.1c8cf574.js:1102:25330)
    at Kf (main.1c8cf574.js:1102:44207)
    at mh (main.1c8cf574.js:1102:42943)
    at Vf (main.1c8cf574.js:1102:41960)
    at d4 (main.1c8cf574.js:1102:38431)
    at Hl (main.1c8cf574.js:1100:3311)
    at main.1c8cf574.js:1102:35725

Expected behavior

It looks like it is an issue with mapping to the component structure, naturally the translation should succeed.

Screenshots If applicable, add screenshots to help explain your problem.

System (please complete the following information):

• OS: [e.g. Linux]
• Browser brave
• Versions:
  • strapi: 4.24.0
  • strapi-plugin-translate: 1.2.4
  • provider: [email protected]

Plugin config Please add your plugin config here, e.g.

module.exports = {
  translate: {
    enabled: true,
    config: {
      // Choose one of the available providers
      provider: "deepl",
      // Pass credentials and other options to the provider
      providerOptions: {
        // use custom locale mapping (for example 'en' locale is deprecated so need to choose between 'EN-GB' and 'EN-US')
        localeMap: {
          // use uppercase here!
          EN: "EN-US",
        },
        apiOptions: {
          formality: "default",
        },
      },
      translatedFieldTypes: [
        "string",
        { type: "json", format: "plain" },
        { type: "text", format: "plain" },
        { type: "richtext", format: "markdown" },
        "component",
        "dynamiczone",
      ],
      translateRelations: true,
    },
}

Additional context Add any other context about the problem here.

[afzal155]

To fix this issue, you need to add the following patch file code along with the specified versions: Versions:

• strapi: 4.10.5
• strapi-plugin-translate: 1.2.5
• provider: [email protected]

Solution:

diff --git a/node_modules/strapi-provider-translate-deepl/lib/index.js b/node_modules/strapi-provider-translate-deepl/lib/index.js
index 093a1f8..3f7ba2f 100644
--- a/node_modules/strapi-provider-translate-deepl/lib/index.js
+++ b/node_modules/strapi-provider-translate-deepl/lib/index.js
@@ -81,7 +81,8 @@ module.exports = {

         const result = reduceFunction(
           await Promise.all(
-            chunks.map(async (texts) => {
+            chunks.map( async ( texts ) => {
+              const newTexts = texts.map( item => typeof item !== "object" ? item : Array.isArray( item ) ? item : JSON.stringify(item) );
               const result = await rateLimitedTranslate.withOptions(
                 {
                   priority:
@@ -89,7 +90,7 @@ module.exports = {
                       ? priority
                       : DEEPL_PRIORITY_DEFAULT,
                 },
-                texts,
+                newTexts,
                 parseLocale(sourceLocale, localeMap, 'source'),
                 parseLocale(targetLocale, localeMap, 'target'),
                 { ...apiOptions, tagHandling }

Its perfectly working fine for me.

[Anuja-More-HFN]

I am using google provider facing same issue i am having one field which accept json { "Styles": { "height": "200px", "background-position": "center-right" }, "className": "container-fluid" } any update on it

[sargreal]

Hi you all,

Thank you for opening and engaging with this issue!

so my first intuition with this issue is, that translating json is not really advised. At least in the two examples, the content of the json field does not include anything that should be translated (in my opinion). Possibly geojson might include some descriptions or something that might need to be translated.

Specifically the issue comes from the plugins configuration:

translatedFieldTypes: [
        "string",
                                \/ the format of json is not plain text!
        { type: "json", format: "plain" },
        { type: "text", format: "plain" },
        { type: "richtext", format: "markdown" },
        "component",
        "dynamiczone",
      ],

By removing the { type: "json", format: "plain" } from the translatedFieldTypes, this issue is resolved and the json values will be copied on translation. It may also be helpful to mark the specific fields as not localized.

If however you require the translation of some json fields, there is in my opinion only one option: "custom field transformations".

My reasoning here goes as follows: If you have a json field, this will probably have some specific format. Transforming that into just string with JSON.stringify, the translation provider may not return a result that either matches this format or matches JSON at all.

By creating custom transformations, you would be able to select exactly the specific fields that you want to translate, and translate those. And if you still want to translate JSON stringified, you can do this as you want to.

I am creating a new issue for custom field transformations, as this can be regarded as a larger feature. However, since I am currently working on the strapi-v5 migration I cannot implement this right now. If you need this, feel free to open a pull request.

[Anuja-More-HFN]

Hi, Thank you for your detailed response and insights.

I completely agree that translating JSON fields is not typically advised, especially since the structure and format of JSON are not suited for translation as plain text. In our case, we don’t require the JSON fields to be translated. However, we’ve noticed an issue where even untranslated JSON fields are causing problems during the save process.

Here’s the error we’re encountering:

TypeError: (i.doc || "").split is not a function at na.create (main.1c8cf574.js:3702:27812) at main.1c8cf574.js:3711:66977 at Li (main.1c8cf574.js:1102:25330) at Kf (main.1c8cf574.js:1102:44207) at mh (main.1c8cf574.js:1102:42943) at Vf (main.1c8cf574.js:1102:41960) at d4 (main.1c8cf574.js:1102:38431) at Hl (main.1c8cf574.js:1100:3311) at main.1c8cf574.js:1102:35725

[fekide-bot]

:tada: This issue has been resolved in version 1.2.6 :tada:

The release is available on npm package (@latest dist-tag)

Your semantic-release bot :package::rocket:

[fekide-bot]

:tada: This issue has been resolved in version 1.1.14 :tada:

The release is available on npm package (@latest dist-tag)

Your semantic-release bot :package::rocket:

[fekide-bot]

:tada: This issue has been resolved in version 1.0.13 :tada:

The release is available on npm package (@latest dist-tag)

Your semantic-release bot :package::rocket:

[Anuja-More-HFN]

Thank you for addressing this issue promptly! I have verified the fix in the locale environment, and everything is working as expected. I appreciate your effort and support. 🎉

[fekide-bot]

:tada: This issue has been resolved in version 1.3.0-next.2 :tada:

The release is available on npm package (@next dist-tag)

Your semantic-release bot :package::rocket: