Skip Navigation

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

Problem:
After updating the Contact Form 7 Multilingual plugin, the client encountered issues with the Acceptance checkbox containing a link. The Advanced Translation Editor (ATE) did not recognize the checkbox correctly, treating the link as plain text and misinterpreting the form tags, leading to incorrect display and translation issues.
Solution:
We created a sandbox to replicate and analyze the issue. The problem was identified as the addition of a 'wpmlcf7-1' tag to the acceptance checkbox, which ATE did not process correctly. To resolve this, we recommended:

  1. Edit the translation in the Advanced Translation Editor.
  2. Search for 'wpmlcf7' in the search area.
  3. Find 'wpmlcf7-1-acceptance' with the shortcode tag.
  4. Translate it by replacing 'wpmlcf7-1-acceptance' with 'acceptance'.
  5. Complete the translation without altering the submit button underneath.

This workaround should correct the display of the checkbox. We have also escalated the issue to our compatibility team for a permanent fix.

Please note that this solution might be outdated or not applicable to your specific case. We highly recommend checking related known issues at https://wpml.org/known-issues/, verifying the version of the permanent fix, and confirming that you have installed the latest versions of themes and plugins. If the issue persists, please open a new support ticket at WPML support forum.

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 7 replies, has 2 voices.

Last updated by Bobby 5 months, 3 weeks ago.

Assisted by: Bobby.

Author Posts
June 24, 2024 at 9:20 pm #15811744

olegA-5

Background of the issue:
I updated the Contact Form 7 Multilingual plugin. I am trying to use the Acceptance checkbox (hidden link) when there is an a-tag inside it. Here is an example of such a checkbox: [acceptance radio-test]hidden link">smth here[/acceptance].

Symptoms:
The updated Contact Form 7 Multilingual plugin turns the Acceptance checkbox into an absolute mess in ATE when trying to translate. I had to manually correct everything over the top of the translation on my website.

Questions:
Why does the updated Contact Form 7 Multilingual plugin not handle the Acceptance checkbox correctly when there is an a-tag inside it?
How can I fix the issue with the Acceptance checkbox in ATE when trying to translate?

June 25, 2024 at 12:52 am #15813051

Bobby
Supporter

Languages: English (English )

Timezone: America/Los_Angeles (GMT-08:00)

Hi there,

Before updating the plugin was everything working OK?

Also to understand better, what is the issue you are experiencing, did the contact form break or is the string not translatable?

June 25, 2024 at 11:10 am #15819731

olegA-5

Yes, everything worked fine. It was an old form that had been translated by ATE a long time ago. I had to make a change to it. Before I did that, I updated the plugin. As I suspect, the updated plugin just doesn't know about the Acceptance checkbox, somehow the information about it got lost in the update. This is a very specific checkbox because it can contain a link. Accordingly, inside the form tags (of which this checkbox has two - opening and closing, although a normal checkbox has one) there is a link with all its attributes, as well as additional text. What I see in ATE is that ATE sees the closing bracket of the first tag and the opening bracket of the second tag as separate strings for translation (consisting of one character each), i.e. it thinks that the form tag should be one, like a normal checkbox. It doesn't display the link correctly at all (it treats it as plain text because it probably thinks that there can't be a link inside a checkbox - and for a regular checkbox this is indeed the case), it adds quotes to it (which are of course in the tag, but which shouldn't be translated along with the href), but in this form the link can't be translated correctly. ATE registers each word within this tag separately. Well, it is obvious that it does not understand how to work with this tag, it does not recognise it and cannot process it correctly. If you try to translate everything through ATE (i.e. actually adding the correct link in the target language with quotation marks, as seen in the original), the frontend is a complete mess. I think this can all be easily seen in the sandbox on any simple tag of this type.

June 25, 2024 at 6:04 pm #15824066

Bobby
Supporter

Languages: English (English )

Timezone: America/Los_Angeles (GMT-08:00)

Thank you for the information!

I have created a sandbox for us to investigate this behavior further.

You can access it using this link:
hidden link

I created a simple Contact Form and added the acceptance box as follows

[acceptance term_and_conditions class:required] I can confirm I have read and accepted the <a href="<em><u>hidden link</u></em>">Terms and Conditions</a>.[/acceptance]

You can see it working OK hidden link" rel="noopener" target="_blank">here in the default language.

The translation is showing broken, you can see it hidden link" rel="noopener" target="_blank">here

Please confirm that this is the issue you are experiencing before I further investigate to make sure we are testing the correct issue.

-------------------

Notice that the tag is showing [wpmlcf7-1-acceptance rather than [acceptance, I believe the issue is caused due to the wpmlcf7-1 tag being added.

A workaround you can use to resolve this is to do the following:

1. Edit the translation in the Advanced Translation Editor
2. Use the search area at the top left and search for 'wpmlcf7'
3. You will see the result in this case for 'wpmlcf7-1-acceptance' with the shortcode tag
4. Translate it and for the translation add only 'acceptance' (see screenshot)

NOTE: Do not translate the submit button underneath it

5. Click on Complete translation & now the checkbox will show OK.

June 25, 2024 at 7:35 pm #15824902

olegA-5

Yeah, that's pretty much what I see. This workaround won't work for me because I've already tried to translate the strings that ATE required to be translated (such as square brackets and links combined with quotation marks), and I've saved those translations in my translation memory. Besides, the ATE wouldn't let me finish the translation without translating those parts anyway (like, again, incorrect links). So I just corrected the translation in the WP editor. The other thing is that if I make changes to the form, I have to make those edits manually every time, but I only have one form with the Accept checkboxes, so it's not a big deal. I hope this will be fixed. I also hope that something like this won't happen with the upcoming, as I understand, core system update (it's announced in the description of this plugin's update). I also really hope that the core system update will avoid the need to make changes to already translated texts when the originals are changed (not in part of an actual change to the originals, of course). For example, because of the change in the Contact Form 7 Multilingual plugin, I had to retranslate radio buttons with labels in all forms (I can see why - this is almost the main change in the plugin mentioned). I'm grateful that now I don't lose translations in this part if I change the original form as it used to be. But it's a pity that I had to retranslate already translated forms (because ATE now "sees" these parts of the forms differently). But I don't have that many forms and they are only translated into a few languages, whereas some pages of my website are translated into 38 languages. I reeeally don't want to re-translate them when changes are made to the core system, as is the case with this plugin.

June 25, 2024 at 8:07 pm #15825240

Bobby
Supporter

Languages: English (English )

Timezone: America/Los_Angeles (GMT-08:00)

I understand. I will be letting our team know about this issue and it will be addressed accordingly.

In the meantime please proceed with either the workaround suggested or the one that you found works best in your case scenario.

June 25, 2024 at 8:20 pm #15825329

Bobby
Supporter

Languages: English (English )

Timezone: America/Los_Angeles (GMT-08:00)

Escalated to compatibility team

June 27, 2024 at 5:23 pm #15845742

Bobby
Supporter

Languages: English (English )

Timezone: America/Los_Angeles (GMT-08:00)

Our team located the issue and will be implementing a permanent fix for this.

In the meantime, you can use my previously suggested workaround OR edit manually the form in the secondary languages and adjust the acceptance shortcode (once it has been translated with ATE).

July 7, 2024 at 5:07 am #15906026

olegA-5

The update fixed everything, thank you!