Please make sure to update to WPML 4.3.5 and check our list of Known Issues before reporting

Hi, Amit here, I am the WPML Support Manager, our current ticket queue is high, update your WPML plugins and make sure you meet the minimal requirements for running WPML before reporting an issue please - many tickets are resolved doing that

Please look at our updated list of Known Issues and you can also use our support search to find helpful information and of course review our documentation before opening a ticket.

If you do need to open a ticket please make sure to provide us with all the needed information as described in this page

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: 

This topic contains 34 replies, has 3 voices.

Last updated by Alejandro 1 day, 16 hours ago.

Assigned support staff: Alejandro.

Author Posts
November 3, 2019 at 5:21 pm

noamK-2

Hello,

Please Note: The front-end password is along side the WP ADMIN password.

1. Our website's main Language is English. Secondary is Hebrew - a right-to-left language.

2. We use Classic Translation Editor for translating all our content, except when it is required to use string translation.

3. WordPress version, theme version and all plugins are all up-to-date. Our theme - Consulting Theme by StylemixThemes, is on your list of compatible themes.

4. Our Issue

4.1 Our Issue started after recent updates to the WPML plugins and the way string translation now works (see WPML article here https://wpml.org/2019/10/wpml-4-3-with-revamped-string-translation/).

4.2 We use the YITH WooCommerce Product Add-Ons plugin, which is on your list of WPML compatible plugins (see https://wpml.org/plugin/yith-woocommerce-product-add-ons/).

4.3 The Text Area addon's Description Field string, is properly translated to Hebrew on WPML String Translations. See hidden link .

4.4 However, on front-end, on the Hebrew product pages that that this addons appears in, the Hebrew translation of the Text Area addon's Description Field is missing. Instead, the English original is displayed.

See for example on the this product page >> under the middle tab: hidden link .

See also a marked screenshot hidden link .

4.5 Together with YITH support, we found out that the only way to make this translation appear correctly on the Hebrew Product page, is if we check the checkbox box Look for strings while pages are rendered found at the bottom left of the Sting Translation page. See hidden link .

4.6 We followed the instruction there, checked the checkbox, and went to front-end to render the pages.

4.7 However, after that, when we unchecked the checkbox, the translation disappeared again.

4.8 We tried to look online for similar tickets relating to this issue and found only this one that may hint the direction, but we are not sure:

https://wpml.org/forums/topic/string-translation-appear-before-disappearing-on-the-frontend-since-wpml-update/

Can you please help?

Thank You,

Noam Kroll

November 3, 2019 at 6:15 pm #4877401

Amit
Supporter

Hi Noam, this seems to me like a duplication of the issue you reported on Friday last week - https://wpml.org/forums/topic/after-recent-wpml-update-all-page-builder-strings-are-missing-from-string-trans/

This was escalated to our developers.

Is there any NEW issue that was not reported to us here? If yes can you please share its details so we can debug and see what's going on?

November 3, 2019 at 6:26 pm #4877407

noamK-2

Shalom Amit,

Thank for your prompt reply over the weekend. Greatly appreciated!!

This issue is actually NEW. Not related to the previous issue I reported at all!!!

The previous issue was pretty simple, and the hack provided resolved it for the time being.

This new issue looks like a pretty complicated thing. I found a few tickets in which people reported similar things:

https://wpml.org/forums/topic/string-appears-translated-only-if-auto-register-strings-option-if-activated/

https://wpml.org/forums/topic/string-translation-appear-before-disappearing-on-the-frontend-since-wpml-update/

https://wpml.org/forums/topic/wpml-and-makecommerce-problem/

Can you please assign it to someone how can help?

Thank you!

Noam Kroll

November 4, 2019 at 10:31 am #4879767

noamK-2

Shalom Amit,

Did you assign this ticket to someone who can help, as requested in my reply to you (above)?

Thank you,

Noam Kroll

November 4, 2019 at 3:18 pm #4882629

Alejandro
Supporter

Languages: English (English ) Spanish (Español ) Italian (Italiano )

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

Hello!

Yes, Amit Assigned it to me and i'm checking out the issue.
I have personally just fixed a very very similar issue and in order to proceed i'd like to have the permission to do the following:

1) Disable the caching plugins and erase their cache files
2) Modify the .htaccess file and maybe reset it to the original
3) Check the wp-config file and modify it if necessary.

In order to do this, i will need FTP Access (which you already provided, i'm just telling you in case you notice access through FTP by someone other that you).

Please let me know you confirm giving me permission. i'll back every file i'll modify up (when needed) but i suggest you still go ahead an do a backup of your own.

Regards.

November 4, 2019 at 5:17 pm #4883549

noamK-2

Hello Alejandro,

Thank you very much for your reply.

Before we proceed, since you say you have already fixed similar issues, can you let me know what was the bottom line?
Where does the issue come from?

Thank you,

Noam Kroll

November 5, 2019 at 1:21 pm #4889431

Alejandro
Supporter

Languages: English (English ) Spanish (Español ) Italian (Italiano )

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

The problem is that there is something in your server or installation that is preventing the files from being written/created in the wp-content/languages/wpml, these issues change per server and in order to check if the same applies to you, you can go to WPML > String Translation > Auto Register Strings for translation.

Check that option and go to the front-end, you'll see if the strings appear correctly translated then (if you have already translated them, of course).

I recommend you check if the folders (including public_html or the root parent folder) have the correct permissions (755 or 750 to the folders and 644 to the files)

you can also check if there are extra definitions in the wp-config.php file and comment them in the meantime if that's your case.

Try it and let me know how it goes.

Regards.

November 5, 2019 at 1:25 pm #4889445

Alejandro
Supporter

Languages: English (English ) Spanish (Español ) Italian (Italiano )

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

Oh yes, please update the plugins to 4.3.3 and related add-on versions please, because part of one of a similar issue is already fixed in there. i'm not dure if it's the same, but at least we can start isolating the problem.

You can check the latest releases in here: https://wpml.org/account/downloads/

November 5, 2019 at 1:41 pm #4889633

noamK-2

Hello Alejandro,

Thank you very much for your reply.

1. This issue started immediately after the introduction of WPML 4.3 with Revamped String Translation. It has never occurred previously. So we know where it comes from.

2. As I wrote in my initial correspondence above, we assume the issue lies here, as Amir Helzer is pointing out in his article on the change:

"The String Translation admin looks the same but works differently. Instead of reading translations from the database, it generates and loads .mo files."

3. In one of the WPML support tickets we found on the internet, as I mention in my initial correspondence above, which deals with similar issue, they say the following interesting thing:

"Since the update, WPML prioritizes the file in the database entry, over the .mo file generated from the database, in wp-content/languages/wpml. So that the translations made through String translations afterwards, were not used anymore.

Deleting the entries referring to these old imported .mo and .po files in icl_mo_files_domains solves the problem."

What do you think?

4. Yesterday, WPML have released their recent versions of the WPML plugins. So we have updated the WPML plugins to their recent version.

5. We hoped that this update will resolve the issue with the Addon strings. Unfortunately it didn't.

6. BUT, what happened right after the update is that the specific string of the Description field in the Textarea addon on the Hebrew product page, got fixed, and now shows the Hebrew translation OK.

However, other addon strings are skewed now, showing the English text instead of the Hebrew translation. And again, this could only be fixed if you check the checkbox at bottom left of the Strings Translation page - "Look for strings while pages are rendered".

And as we pointed out, If you uncheck the checkbox, it gets skewed again and the English text will be displayed instead of the Hebrew text.

7. You can see the new skewed Addons here on this Hebrew product page for example: hidden link

You need to go to the middle tab, select "3 market pricings", and then select "Enter Position Information Online" (all in Hebrew, sorry :)).

See marked screenshot hidden link . As you can see, 3 strings are now displaying the English text instead of the Hebrew translation.

Any thoughts?

Thank you

Noam Kroll

November 5, 2019 at 3:25 pm #4890821

Alejandro
Supporter

Languages: English (English ) Spanish (Español ) Italian (Italiano )

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

I see.

It seems to be a bit different from the issue i had seen before but one of our developer is looking into this. removing the data manually from the database (they are in different tables so i suggest you don't try it yourself) will unfortunately not change anything (i just tried it on another installation with the same issue) but if we migrate this site to one of our servers, for example, will fix it somehow, that's why i said there is something either in the server or that links the server into the equation).

I haven't touched your site (i mean, i haven't modified anything, i just looked at it), by the way, but i did see that the problem is eactly the same as another one we are already troubleshooting so whenever i have news on that one, i'll try it on your installarion (with your permission, or maybe i will just let you know and you can do it yourself if that suits you better).

Regards.

November 5, 2019 at 4:39 pm #4891691

noamK-2

Hello Alejandro,

I have just updated the Duplicator files in the link I gave you. All plugins are up to date there.

My question:

Why can't you do all the tests in your environment with the Duplicator files, instead of doing the tests on our website? It would be much better,

Thank you,

Noam Kroll

November 6, 2019 at 8:29 am #4895625

Alejandro
Supporter

Languages: English (English ) Spanish (Español ) Italian (Italiano )

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

Hello,

I checked the page but i couldn't find the strings in the screenshot. can you guide me through with the text in hebrew please so i can try to check where are those strings coming from?

and the reason why i'm doing everything on your site is because this particular issue is reproduceable on the duplicator, yes, but our servers have all the correct permissions so they are fixed right away as soon as we resave the translations. so it's more of a server configuration than something else and we need to rule out this scenario first in order to jump and test everything on the duplicator directly.

In m tests i can see the .mo files being created correctly so i believe that this problem is something different than the one i previously thought..

November 6, 2019 at 5:06 pm #4900533

noamK-2

Hello Alejandro,

1. We have just verified with our host SiteGround that all permission are as you indicated.

2. The strings issue is associated with the YITH Product Addons plugin (which is on your list of WPML compatible plugins).

3. This problematic strings are part of the addons we created with this plugin, for our products page. All the Addons strings are translated properly to Hebrew.

4. Currently, the only way to make these 3 strings display the Hebrew translation on front-end, is if you check the checkbox Look for strings while pages are rendered found at the bottom left of the Sting Translation page. See hidden link .

However, if you uncheck the box, the 3 strings get skewed again and will display the English text instead of the Hebrew translation.

This phenomena MUST give you some hint as to where the issue lies!!!!

5. You can see the 3 skewed Addon strings here on this Hebrew product page for example: hidden link

5.1 You need to go to the middle tab - See marked screenshot hidden link

5.2 select "3 market pricings" - see marked screenshot hidden link

5.3 and then select "Enter Position Information Online" - see marked screenshot hidden link

And now you can see the 3 skewed addon strings that display in English instead of Hebrew - see marked screenshot - hidden link .

6. Please do ALL your test using the Duplicator plugin package, on your local installation, and not on our website.
I have just uploaded the most recent and updated package to our Google Drive (you have the link).

Thank you,

Noam Kroll

November 7, 2019 at 9:46 am #4904283

noamK-2

Hello Alejandro,

As a follow-on to my previous message which you still HAVEN'T REPLIED:

We were just issued an alert by Wordfence, that some modifications were made to the following WPML plugins on our website - see screenshot: hidden link

Is that something that you have performed on our website?

Thank you,

Noam Kroll

November 7, 2019 at 10:21 am #4904655

Alejandro
Supporter

Languages: English (English ) Spanish (Español ) Italian (Italiano )

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

Our developer Pierre actually replied 2 days ago and actually provided a solution for the problem on your other ticket, although the change was supposed to go in functions.php and he didn't add it himself to the site as far as i know, he asked you to do it.

I haven't updated anything (the files on the screenshot seem to be coming from an update, though) so no, that wasn't me.

I was off my shift when you wrote that last message (which i'm checking right now) so i'll update you briefly (I'm checking everything).