This is the technical support forum for Toolset - a suite of plugins for developing WordPress sites without writing PHP.
Everyone can read this forum, but only Toolset clients can post in it. Toolset support works 6 days per week, 19 hours per day.
No supporters are available to work today on Toolset forum. Feel free to create tickets and we will handle it as soon as we are online. Thank you for your understanding.
| Sun | Mon | Tue | Wed | Thu | Fri | Sat |
|---|---|---|---|---|---|---|
| - | 7:00 – 14:00 | 7:00 – 14:00 | 7:00 – 14:00 | 7:00 – 14:00 | 7:00 – 14:00 | - |
| - | 15:00 – 16:00 | 15:00 – 16:00 | 15:00 – 16:00 | 15:00 – 16:00 | 15:00 – 16:00 | - |
Supporter timezone: Europe/London (GMT+01:00)
This topic contains 44 replies, has 4 voices.
Last updated by Nigel 2 months, 2 weeks ago.
Assisted by: Nigel.
Hi Waqar
Hmm, if I'm understanding you right, what you're saying is that the original form is somehow corrupted? Or do you suspect the WPML or the translation element of the problem to somehow be the culprit?
In WPML settings the Post Forms are marked as "Translatable", (see screenshot) however when I'm in the Post Forms Screen, I cannot see the WPML language switching flag (see screenshot) to view or edit the DE version of the form. The WPML language switching flag only appears after going into translation mode (see screenshot), but once there, it has no effect. I can't switch it from EN to DE for example.
This has always been puzzling to me that the translation of forms is so different to the translation of other post types, eg Pages.
Our Toolset Forms are all created initially in EN and in order to show the user a German version I have to add very "manual" WPML string translations for the DE headings using [wpml-string] shortcodes like
[wpml-string context="toolset-forms-xxx" name="xxxxxx"]some string[/wpml-string]
This is different from the way most content is translated, where you see the original language on the left hand side for each element of the page/post etc and the equivalent element on the right hand side which you can translate in each box.
I only have the possibility to translate the post (form) name and its HTML content all in one go and then need to manually verify all the DE
[wpml-string]
shortcodes. Is that how Toolset intends this to work? The only logical explanation I have is that it is due to the fact that we were forced to use the "Expert mode" to display all the elements we needed in the form? However, that doesn't explain why the WPML flag is missing when viewing the list of original EN forms and has no effect when changed in translation mode. (Why display the flag at all, if it has no purpose?)
Thanks and kind regards
Simon
Hi Minesh
Hope you are well. Thanks for the short update, however my questions are not yet answered.
The online help "https://toolset.com/course-lesson/translating-views-content-templates-archives-and-forms/#translating-forms" just says "Forms are translated just like other Toolset elements, as described above. However, if you install WPML after creating your Toolset forms, you must resave the forms for them to appear on the WPML Translation Management page." and nothing else. Our forms have been saved many times since WPML was installed.
If I open a Toolset Form in our site, there is a pencil icon (see screenshot) which indicates that a WPML translation ALREADY EXISTS somewhere and when I click it I get to the screen shown in my previous update where I can translate the Title of the DE form and and the code.
However, if I go to the Translation Management screen (see screenshot), it tells me that all our Toolset Forms are NOT translated. So the two screens are contradicting each other.
The only reason why I use [wpml-string] shortcodes sometimes, is because I wish to add some text below a field heading for example to provide clear information to the user about how they should enter data in that field of the form. This text string is not part of the custom field title string, so I don't have any other choice but to use [wpml-string] shortcodes.
Furthermore, I do not believe that Custom Code has a role to play here regarding translation. The only custom code regarding forms we have is to validate form content entered on the forms, eg to check that required fields are filled in etc.
Kind regards
Simon
Nigel
Languages: English (English ) Spanish (Español )
Timezone: Europe/London (GMT+01:00)
Hi Simon
I ran some tests on my local site to compare what I see and what you are describing.
I think the confusion is arising because yours is an older site, while the advice in the documentation is based on the current implementation.
With the switch to Blocks from Views there was a major WPML compatibility update, to make translation of Toolset elements like Views and custom archives and forms easier to translate, via WPML Translation Management.
On a new, clean multilingual site, when editing a form you do not see the language information you shared in your screenshot.
On such a site, if you go to WPML > Settings > Post Types Translation and check the post types for forms, you'll see the post types are set to not translatable (screenshot). The text from the forms can be translated via Translation Management, so that if you add the form to a page, and translate the page, you can see different language versions of the form on the front end, but there is only one form (a form post), so only one set of settings and notifications, even though all of the texts are translated.
On your site I expect if you check the WPML settings for the form post type you will see that it is set to translate, meaning there are different forms (different form posts) for each language, each with their own settings and their own notifications.
For an existing site like this I would ignore the current advice about using Translation Management to translate the forms.
If you have forms set as translatable, then I would expect that if you are editing the form in English you should have the language switcher in the admin toolbar and be able to switch to edit the German version of the form. Do that and double-check that all of the settings, including the available notifications look correct, and re-save the form.
Try creating a test post with that form and check the notifications again.
If it is still the wrong notification let us know and we can look in the database at the form settings saved for the translated form to try and determine why.
Hi Nigel
Thanks for those insights. I spent some hours doing a few tests, but everything is still not working as expected:
1) When WPML > Settings > Post Types Translation is set to Translate for
- Post Forms (cred-form)
- User Forms (cred-user-form)
there is still no language flag when listing the the Post Forms (see screenshot), or while editing one (see screenshots). Is that expected?
2) When WPML > Settings > Post Types Translation is set to Not Translatable I see no difference, except that the WPML Language box disappears when editing the post form.
3) I created a brand new version of "Post Form - New Job Ad (ID: 929)", called "Post Form - Create Job Ad (ID: 26883)" with Translate set to OFF as you suggest in WPML > Settings > Post Types (ie the "new" way, where we have one post with just string translations).
3a) After creating it, I went to WPML > Translation Management and sent it to the Translation Queue.
3b) I was presented with a hyperlink to take me directly to WPML > Translations, which I did, and translated it.
3c) Under WPML > Translation Management, the "Post Form - Create Job Ad" appears at the bottom with a green translated icon (also in the screenshot), which seems logical, however, when I go back to WPML > Translations to examine the queue, I do not see the translation listed when I filter for Post Forms (see screenshot), only when I filter for Toolset Forms. What is the difference between the post types "Post Form" and "Toolset Form"? Are these both post types "Post Form (cred-form)"? If yes, then that's really confusing.
3d) What is the ID being shown in Translations Queue? The ID of the Translation? The new form I created was ID 26883, however I'm seeing ID 2872 for the new "Toolset Form" "Post Form - Create Job Ad".
3e) Also, when I am in WPML > Translation Management, and filter for Toolset Forms, I can see a Form "TEST" (see screenshot), which I cannot see in the list in Toolset > Post Forms. (This may be one created by Toolset while testing, but how do I delete it?!)
3f) When I translated the form using the new translation style, I was not prompted to translate ALL the strings. Comparing the string translations for toolset-forms-26883 and toolset-forms-929 (see screenshot), there is a difference of 3 strings. I was able to identify 2 of the strings as explanatory texts in the original 929 form using
- [wpml-string context="toolset-forms-929" name="Warning text"] and
- [wpml-string context="toolset-forms-929" name="Use search terms"]
but I'm not sure what the 3rd missing one is.
4a) You say that our site is classed as "older" or "legacy", because it was built originally using Toolset Views. Is this "legacy" way of doing things always going to be supported? Or is it recommended to "upgrade" and/or phase out older stuff and replace with the newer way of doing things?
4b) Do you suspect there are "German versions" of our English Post Forms still on the database, which we cannot see/access/delete via the GUI, which are obsolete and theoretically could/should be deleted?
Ideally, my ultimate goal is to get our site using the up-to-date way of creating and translating forms, and more importantly removing any obsolete data in the database which wouldn't be there if everything was created "the new way". However, as you can understand, I don't want to go ahead and re-do all the forms if we are still gonna get missing translations, or incorrect notifications going out in the secondary languages.
Thanks and regards
Simon
Nigel
Languages: English (English ) Spanish (Español )
Timezone: Europe/London (GMT+01:00)
This ticket is now closed. If you're a WPML client and need related help, please open a new support ticket.
