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

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

Last updated by Andreas W. 2 months ago.

Assigned support staff: Andreas W..

Author Posts
November 19, 2019 at 7:27 pm #4975499

antonS-31

Hi Andreas,

The answer I got from Gravity Forms is that the bug appeared after installing WPML, in which they have no expertise. I have re-interated now again, stating that the bug appears before the WPML installation and I'm waiting for their answer (they are usually pretty quick)

So you are advising me to switch to Classic for the whole site, basically? That would let me edit the gravity form. To be honest I don't think I make use of the "Advanced" features as the machine translation is rubbish and generally don't need spellcheck.

And PLEASE let me know about the "values" entries as I have conditional logic and nothing works if I don't leave my values with the original language string.

I had already updated all the WPML plugins to the beta released on 18th Nov before my last reply.

So to re-iterate (pls read the first message in the thread and the errors there) - when Gravity Forms Multilingual is disabled, all works fine. But when I enable that plugin, the form does not show the last page of the form - instead it simply submits it without the information. Yes, the frontend isn't showing the last page at all. That occured today when I was testing and you can see the resulting entry in GF doesn't have the last items (most notably the payment info)

MISSING: hidden link

CORRECT:
hidden link

Do I need the GF Multilingual plugin at all?

Also about the newly developed feature (I guess that effects everyone with GF and WPML) - do I need to start over with the GF translations and does work well with the GF Multilingual plugin

November 19, 2019 at 9:36 pm #4975987

Andreas W.
Supporter

Languages: English (English ) Spanish (Español ) German (Deutsch )

Timezone: America/Lima (GMT-05:00)

Hello,

Thank you again for the clarification and my apologies for the delay on the issue as we been handling a heavy queue lately.

Now, when coming back to our testing site I realized that the errors on your form which are disappearing once String Translation are disabled.

One-Click Login: hidden link

You can see the errors here:
hidden link

Now, I created a new form including a dropdown with conditional logic and the issue does not appear.
hidden link

Now here, you see a duplicate of your form on which I removed all fields and left the 5 dropdowns active - no errors - but I see that one dropdown is not vidualized:
hidden link

Could you please review that and investigate the missing dropdown. I would suggest recreating it in your form and check if the issue persists.

I am really sorry for taking so long to analyze the issue but it is a huge form and I was not able to point out which item or setting caused the issue which I would kindly like to ask you for your assistance in recreating the error on the test-site.
Before being able to escalate the issue it is mandatory for me to figure out if we are handling compatibility issue or if it is a bug which is causing the issue.

Please have a last look at the test site and try recreating the error on a new form or try to solve it on a duplicate of your imported form. It seems to me as if the error would not appear if the form is getting created again.

Now, for your question about the Classic Translation Editor. If you already translated content using the Advanced Translation Editor it is not advised to change back to Classic Translation Editor for all the content.

I would advise you to leave the setting for the Advanced Translation editor active, only as long you already translated various pages with this editor.
Otherwise, changing back to the Classic Translation editor might cause the loss of existing translations.

Kind regards
Andreas

November 20, 2019 at 3:15 pm #4981581

antonS-31

Hi Andreas,

This prooved more difficult than I thought.
The good news is that I managed to find what was causing the last page not displaying. This was linked to your original question about Gravity Perks and the errors raised. Basically I was creating a coupon in GF in a currency that didn't exist yet (I moved the custom currency creation from function-child.php to function.php, just before the creating of the coupon with that currency).

The biggest functional obstacle is that STILL THE CONDITONAL confirmations don't work with Gravity Forms Multilingual enabled. I'm not yet able to replicate on your test instance, but I ran Health Check & Troubleshooting 1.4.2 plugin and only enabled WPML,GF, GF Multilingual, String Translation with the default theme and I can replicate the fact that the condition for the confirmation page doesn't work.

Basically I'm sending the customers to 3 different pages based on what plan they order (1,3 or 6 month) plan. I have order1,order3 and order6 pages,via a redirection in Gravity Forms.

The condition is simply based on the PRODUCT field in GF that's field 35.
Now, I have quite a bit of html in that field's name.

LABEL:

"<span class="titLe">БЪРЗ СТАРТ</span> <span class="priCe">40 лв.<br/> <span class="white">. </span></span><span class="tiMe">1 месец </br> </span>"

VALUE:"1"

- there are three options with value 1/3/6

As far as the form created by you - I saw that you isolated just a few questions (that's what time you wake up and what time do you go to bed), but I didn't see the conditional logic there - just a dropdown....?

On editors: You don't advise going back to Classic editor, but what is the way that we get the GF translation to work? Also you still didn't see my question about VALUES, please answer that

November 20, 2019 at 8:31 pm #4983991

antonS-31

To answer your question - the 5th dropdown is set as an administrative field- so that's why it doesn't show.

hidden link

November 20, 2019 at 9:47 pm #4984451

antonS-31

OK I managed to configure a confirmation which should redirect, on the main form (id 1)
hidden link

However, it goes to the main default confirmation message "Default Confirmation".
hidden link

I have duplicated the form to ID 5 (and 6 and 7) and I'm testing in "preview" mode and still not getting the redirection to happen. My next step is to try and reduce the form.

I did try removing some of the questions and sections in (2/3/4) without the last page and without the dropdowns you mentioned and it worked! This means that the problem is one of the first fields.

So now I have been deleting fields and testing over and over . It appears that the field that is breaking the submission conditions is one of 77,117,108,106,130 - They aren't anything special and I will investigate further.

November 21, 2019 at 4:11 pm #4990659

antonS-31

SOLVED! The was that there were certain conditions configured in GF for fields, based on values of other fields (dropdowns and radios), but after that I had changed the values of the dropdowns, forgetting to update the already created conditions. This doesn't break GF, but it seems to break GF Multilingual.
As a side question - actually the original Notices that you saw on the sandbox were the pointer - how did you switch them on and how can we get it to show which field exactly it comes from?

So now we can go back to the actual translation.

The main issue is the VALUES which I don't want to translate (again, for the reason of conditional logic)
The second issue is that the translation still sends me to the Advanced translation and I don't have a clear way of switching to Classic ONLY for the GF. hidden link
Again: I don't mind switching to Classic for all translation.

November 21, 2019 at 6:29 pm #4992325

Andreas W.
Supporter

Languages: English (English ) Spanish (Español ) German (Deutsch )

Timezone: America/Lima (GMT-05:00)

Hello,

Did you already create translations with Advanced Translation Editor? If so, take note that it might be necessary to redo that translation when switching back to Classic Translation Editor.

The only way switching back to the Classic Translation Editor is by going to WPML -> Settings -> How to translate posts and pages and selecting the Classic Translation Editor. This is a global setting and will affect all post types.

Now, the only way at the moment to create a translation job on Translation Management and translate it with the WPML Translation Editor.
In regards to our documentation, I can see that the options for the values of condition fields usually need to be translated on String Translation. As our developers informed me that this feature had been removed I suggest translating the forms with the Classic TranslatioN Editor instead.

Were you able to recreate the issue on our test site? How does it behave between translating with Classic Translation Editor or Advanced Translation Editor? Usually, the option values for conditional form values should be translatable with the Classic TranslatioN Editor, but I did not test this yet.

I can see that you created some forms on our test site. Was it possible to create a new short-form using the same conditional logic on our test site and experience the same issue?
Does the form of translation work as expected? Are you able to translate the value fields on our Classic Translation Editor? How does it compare with a new form created to your live site?

One-Click Login: hidden link

Kind regards
Andreas

The topic ‘[Closed] Gravity form isn't shown in String Translation’ is closed to new replies.