Line breaks not showing in translation editor

This thread is resolved. Here is a description of the problem and solution.

Problem:

The Classic Translation Editor is not respecting line breaks.

Solution:

1. Take a backup of your site in case something goes wrong.

2. Open the following file with a code editor.
/wp-content/plugins/wpml-string-translation/classes/class-wpml-st-string.php

3. Search for this line (243):

if ( ! empty( $translation_data ) ) {

4. After the above line, add this code:

if (isset($_REQUEST["action"]) && $_REQUEST["action"] == "wpml_save_job_ajax") {
                    $translation_data["value"] = wpautop($translation_data["value"]);
                }

This will ensure that the values have all been converted to have HTML inside and will avoid the problem.

5. Save the changes.

Now the problem should not occur anymore. You may need to update the translations where this issue occurred before you apply the workaround.
**** Important! Please make a full site backup (files and DB) before you proceed with those steps****

This issue is now escalated to our developers. The fix will be included in future versions of Strings Translation. Until it is included, if there is an update to Strings Translation and you apply it on your site, you need to insert this workaround again.

This is the technical support forum for WPML - the multilingual WordPress plugin.

Everyone can read, but only WPML clients can post here. WPML team is replying on the forum 6 days per week, 22 hours per day.

Tagged: Bug

This topic contains 17 replies, has 3 voices.

Last updated by Itamar 1 year, 2 months ago.

Assisted by: Itamar.

Author	Posts
October 13, 2022 at 3:51 pm #12237425
M	We've been having problem with line breaks on translations since several months ago. The site original language is spanish and it is translated to Catalan using the classic editor. We opened a first support ticket but the person in charge of the issue left the project so we couldn't manage to solve it. https://wpml.org/forums/topic/line-breaks-are-not-respected-on-the-frontend/ We are using only Gutenberg blocks, not Elementor or any other visual editor, only native Gutenberg blocks. You can watch a video with clarifications about the issue here: hidden link
October 13, 2022 at 4:17 pm #12237543
Lauren Supporter Languages: English (English ) Timezone: America/New_York (GMT-04:00)	I would like to request temporary access (wp-admin and FTP) to your staging site to take better look at the issue. You will find the needed fields for this below the comment area when you log in to leave your next reply. The information you will enter is private which means only you and I can see and have access to it. Our Debugging Procedures I will be checking various settings in the backend to see if the issue can be resolved. Although I won't be making changes that affect the live site, it is still good practice to backup the site before providing us access. In the event that we do need to debug the site further, I will duplicate the site and work in a separate, local development environment to avoid affecting the live site. Privacy and Security Policy We have strict policies regarding privacy and access to your information. Please see: https://wpml.org/purchase/support-policy/privacy-and-security-when-providing-debug-information-for-support/ IMPORTANT - Please make a backup of site files and database before providing us access. - If you do not see the wp-admin/FTP fields this means your post & website login details will be made PUBLIC. DO NOT post your website details unless you see the required wp-admin/FTP fields. If you do not, please ask me to enable the private box. The private box looks like this: hidden link
October 14, 2022 at 11:24 am #12242153
M	Also, a new "issue" has been reported today. Looks like some authors, due to not being able to give the correct format from the classic editor, have edited directly some post translations . So these posts were edited switching the language to catalan on the top bar and directly from Gutemberg blocks. As expected, translation pairings are missing for these translations. The problem is that WPML adds the original language text (in spanish) when opening translations with classic editor. If pairings are missing, the right column fields should be empty. Instead, they are populated with the original language and checked, like if they were correctly translated, when they're not. This is post is an example of this behaviour: hidden link As you, can see, the frontend in catalan is looking good now: hidden link However, if you edit the translation with classic editor (clicking on the pencil icon) you'll see that translations are in spanish. It is easy to notice looking at the words Azafrán (saffron in spanish) and Safrà (saffron in catalan). If someone doesn't notice this, saving the translation will delete all catalan strings as they will be replaced with spanish ones. Thanks New threads created by Itamar and linked to this one are listed below: https://wpml.org/forums/topic/split-wpml-adds-the-original-language-text-when-opening-translations-with-classic-editor/
October 18, 2022 at 11:23 am #12260637
Itamar Supporter Languages: English (English ) Hebrew (עברית ) Timezone: Asia/Jerusalem (GMT+03:00)	Hi, I'll continue to help you with this issue. I've watched the video you shared with us, and I can access your site. Can you please explain where to see the line break issue? Which post or page should I edit? As for the new issue you bring - "WPML adds the original language text (in Spanish) when opening translations with classic editor". In our forum, we try to keep one issue per ticket. Please wait for one of our supporters to get back to you in the new split ticket I created. https://wpml.org/forums/topic/split-wpml-adds-the-original-language-text-when-opening-translations-with-classic-editor/ Regards, Itamar.
October 18, 2022 at 4:06 pm #12263323
M	Hi Itamar, Thank you, hope this time you could provide a solution. Feel free to create new posts to check the issue as described here: hidden link You can change the admin language if you feel more comfortable as well. This is just a staging site. In relation to the opening of the new ticket, you forgot to attach the images which I think provide some valuable information to help to solve the problem. Thanks in advance M
October 19, 2022 at 10:20 am #12268407
Itamar Supporter Languages: English (English ) Hebrew (עברית ) Timezone: Asia/Jerusalem (GMT+03:00)	Hi, and thanks for the video. I could replicate this issue on a fresh WordPress installation, so I escalated it to our second-tier supporters. I'll keep you updated here when I have news regarding this issue. Thank you for your patience. Itamar.
October 20, 2022 at 1:07 pm #12279897
Itamar Supporter Languages: English (English ) Hebrew (עברית ) Timezone: Asia/Jerusalem (GMT+03:00)	Hi, Our second-tier supporter debugged this issue and provided a workaround. 1. Take a backup of your site in case something goes wrong. 2. Open the following file with a code editor. /wp-content/plugins/wpml-string-translation/classes/class-wpml-st-string.php 3. Search for this line (243): if ( ! empty( $translation_data ) ) { 4. After the above line, add this code: if (isset($_REQUEST["action"]) && $_REQUEST["action"] == "wpml_save_job_ajax") { $translation_data["value"] = wpautop($translation_data["value"]); } This will ensure that the values have all been converted to have HTML inside and will avoid the problem. 5. Save the changes. Now the problem should not occur anymore. You may need to update the translations where this issue occurred before you apply the workaround. ** Important! Please make a full site backup (files and DB) before you proceed with those steps** This issue is now escalated to our developers. The fix will be included in future versions of Strings Translation. Until it is included, if there is an update to Strings Translation and you apply it on your site, you need to insert this workaround again. I'll update you here on further news regarding this issue. Regards, Itamar.
October 20, 2022 at 3:31 pm #12281305
M	Thank you Itamar, everything looks good so far after updating the code.
November 16, 2022 at 9:34 am #12470711
M	Hello Itamar, After further inspection we discovered that this workaround is introducing p tags on header blocks. Obviously this is bad for SEO, accessibility and formatting. We didn't notice it until today as the fix was not included on the latest two releases of String Translation and we were running on versions without the fix. Thanks in advance Marc
November 17, 2022 at 3:51 pm #12483925
Itamar Supporter Languages: English (English ) Hebrew (עברית ) Timezone: Asia/Jerusalem (GMT+03:00)	Hi, Marc. Until now, we've dealt only with regular paragraph blocks. So the example I gave to our second-tier supporters was with a paragraph block. And the workaround may only work for paragraph blocks. I tried to repeat the same process on my test site to replicate this issue with a Heading block. But I can not reproduce it. Can you please send me a video of the process I need to take? Thanks, Itamar.
November 18, 2022 at 2:03 pm #12490835
M	Hi Itamar, thnk you for the quick reply. Could you please confirm that the fix or "workaround" is not included on the last version of string translation? After applying the "workaround" code this is what we see: hidden link As you can see, after updating the translation p tags are added on header blocks. Thanks in advance Marc
November 20, 2022 at 5:45 pm #12499611
Itamar Supporter Languages: English (English ) Hebrew (עברית ) Timezone: Asia/Jerusalem (GMT+03:00)	Hi, Marc, and thanks for the video. I can replicate this issue on my test and currently consulting our second-tier supporter regarding it. I've noticed that the p tag is added on the second translation of the Heading block. It seems to be happening on even (2,4,6) attempts to update the Heading block. I could correct this issue on my test site by adding a small change to the Heading block and then updating the translation. Please try it also on your site. I'll keep you updated here on the news from our second-tier supporter. Regards, Itamar.
November 23, 2022 at 6:48 pm #12522163
Itamar Supporter Languages: English (English ) Hebrew (עברית ) Timezone: Asia/Jerusalem (GMT+03:00)	Hi, Here is a more efficient workaround that is not causing the a p tag to be added in the heading block. if (isset($_REQUEST["action"]) && $_REQUEST["action"] == "wpml_save_job_ajax" && preg_match('/[\n\r]/', $translation_data["value"])) { $translation_data["value"] = wpautop($translation_data["value"]); } Regards, Itamar.
November 29, 2022 at 6:46 pm #12557335
M	Hi Itamar, how are you doing? Sorry for the late reply. I used the code you provided and everything looked fine but after som testing I found that it is still adding paragraph tags on heading block, at least when these had som html formatting, like line breaks. Switching the tinyMCE to visual and adding the breaks manually solves the problem but obviously there is still an issue here, but at least is less annoying as heading with formatting are far less common that paragraphs. Thank you for you kind support M
December 5, 2022 at 12:04 pm #12590955
Itamar Supporter Languages: English (English ) Hebrew (עברית ) Timezone: Asia/Jerusalem (GMT+03:00)	Hi, and sorry for the late reply. Thanks for reporting this. I've sent this information to our second-tier supporter. Regards, Itamar.

This ticket is now closed. If you're a WPML client and need related help, please open a new support ticket.