Skip Navigation

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.

This topic contains 14 replies, has 2 voices.

Last updated by Marcel 1 month, 1 week ago.

Assigned support staff: Marcel.

Author Posts
October 14, 2021 at 1:51 pm

John-Pierre Cornelissen

Translation doesn´t show on the front end when adding a 🌿

October 14, 2021 at 3:37 pm
October 14, 2021 at 4:47 pm #9792039

John-Pierre Cornelissen

FYI I converted the database to InnoDB with utf8mb4_general_ci and now the translations are shown correctly.

I still feel this is a bug within WPML though, because I can add emoji to the source content without a problem. When in the Classic translation editor, I can also add emoji's. But when the translations are saved, they are not visible on the front end. And when you go back in the editor, they are still there.

Thanks
JP

October 15, 2021 at 4:10 pm #9799695

Marcel
Supporter

Languages: English (English ) German (Deutsch )

Timezone: Europe/Madrid (GMT+01:00)

Hi JP,

this should solve your issue. It's related to page builders: https://wpml.org/errata/using-emojis-with-page-builders-might-make-the-content-not-available-for-translation/.

Could you give this workaround a try?

Best Regards
Marcel

October 15, 2021 at 5:47 pm #9799931

John-Pierre Cornelissen

Hi Marcel,

Please see my previous reply
https://wpml.org/forums/topic/translation-doesnt-show-on-the-front-end-when-adding-a-%f0%9f%8c%bf/#post-9792039

October 18, 2021 at 7:27 am #9807565

Marcel
Supporter

Languages: English (English ) German (Deutsch )

Timezone: Europe/Madrid (GMT+01:00)

Hi,

If the tables are correctly converted to utf8mb4_general_ci, then we don't have any other known issues about this. Would you please add screenshots or a screen video where your mentioned issue is viewable?

You can also install Divi on this isolated Sandbox and try if you can reproduce it from scratch: hidden link

Thank You!

Best Regards
Marcel

October 18, 2021 at 8:05 am #9808051

John-Pierre Cornelissen

Hi, I have the feeling you don't understand what I am saying.

1) it is solved after converting the database

BUT

2) Although it is solved for me after converting the database, I think that should not be needed, because before converting the database, the emoji's were shown correctly in every place except in the published translation.
- Published source: shown correct
- Classic translation editor: shown correct
- Published translation: *not* shown correct

So without converting, wpml has an issue in publishing the translation when it contains emoji's. It's not a WordPress issue nor a Divi issue, because the source is fine.

October 18, 2021 at 8:44 am #9808295

Marcel
Supporter

Languages: English (English ) German (Deutsch )

Timezone: Europe/Madrid (GMT+01:00)

Hi,

our known issue mentions that part of the content is not available for translation if this element contains emojis. The first reports we got came with WPML 4.4.12 and Divi. This is the reason why we provided our clients with a workaround to convert the DB.

... without converting, wpml has an issue in publishing the translation when it contains emoji's. It's not a WordPress issue nor a Divi issue, because the source is fine.

Currently, we don't have any other reports about publishing the translation when they contain an emoji. So if you can reproduce the issue with the actual collation from our test Sandbox, we can check if another workaround is possible too.

If it doesn't happen with the actual DB collation, I would need to know the exact DB collation before changing it to repeat the test using the identical schema.

Best Regards
Marcel

October 18, 2021 at 9:15 am #9808469

John-Pierre Cornelissen

I think this is a slightly different issue. The workaround says

"that block won’t be available for translation in the Advanced Translation Editor or Classic Translation Editor."

This is not the case. the block IS available for translation in the classic translation editor and the block has been translated and saved that way. Now the strange thing is:
1) you don't see the translated content on the published page.
2) if you go back in the translation editor, the translation is still there.

So, the block was translated and saved in the database, just not shown on the published page.

Before I converted the database, the posts table was
ENGINE=MyISAM DEFAULT CHARSET=utf8;

I have an export from before the conversion if that is of any help.

Or we can close this ticket if you like, because the problem is solved for me after converting the database. I just thought that it could/should get a proper fix, but I won't be able to spend a lot of time on it trying to reproduce.

October 18, 2021 at 10:10 am #9808909

Marcel
Supporter

Languages: English (English ) German (Deutsch )

Timezone: Europe/Madrid (GMT+01:00)

Hi,

yes, it's a different issue and as I mentioned before, we don't have any reports for it yet, so we need to check if it's reproducible to see what is causing it. I tried it myself and with the default collation from our Sandbox, the issue is not reproducible:

- Source Language: hidden link -> Emoji appear
- Classic Translation Editor -> Emoji appears: hidden link
- Published Secondary Page: hidden link -> Emoji appear

I configured a new site locally and changed it back to MyISAM and it was there also not reproducible in this configuration. MyISAM was the storage engine used in the past by WordPress, so probably not many sites will be affected. As it's not clearly reproducible, I can take a look at your export if you can share it with me.

Best Regards
Marcel

emoji.png
October 18, 2021 at 10:55 am
October 18, 2021 at 12:44 pm #9810181

Marcel
Supporter

Languages: English (English ) German (Deutsch )

Timezone: Europe/Madrid (GMT+01:00)

Hi,

it seems the zip upload didn't work. Could you please update it on a file hoster and add it again in the "Duplicator" input field?

Thanks!

October 18, 2021 at 1:04 pm
October 19, 2021 at 3:07 pm #9819765

Marcel
Supporter

Languages: English (English ) German (Deutsch )

Timezone: Europe/Madrid (GMT+01:00)

Hi,

thanks for the DB. I imported it on a new site and can't reproduce it there, as publishing new pages (before updating WPML) is not working. As a test, I switched to Classic Editor, where it worked, but pages in default languages are showing 404, even if WPML is deactivated.

I don't see a way to reproduce this with all the errors on your actual DB export. As the main issue is solved, I think we can safely close this.

Best Regards
Marcel

October 19, 2021 at 4:05 pm #9820399

John-Pierre Cornelissen

Hi,

Did you run the 'Better Search Replace' plugin to replace the domain from the export with the one of your test database?

Thanks
JP