Ok Thanks.
I will need you to do the test below to see if the issue is still there or not:
- Add a new sample page
- Create a new view and do not use the conditionals and add something similar to the homepage.
- Check if it works.
- If yes, add just one conditional and try to do the translation.
- See if you can see the issue.
That way, I will be able to check the sample page without the fear of ruining the homepage.
One last thing to check is if the issue can be replicated on the new sample page, check if the manual translation mode works:
https://wpml.org/documentation/translating-your-contents/using-different-translation-editors-for-different-pages/
That way we will know if the issue is ATE or not.
The way WPML works is to create an XLIFF file out of the content of the page and sends that to the ATE server to finish the translation and gets back.
Now with the manual translation working, we will have a theory that the conditional ruins the XLIFF file somehow and I will check that in the sample page.
If the manual translation does not work either we should go for the minimal installation route and do the check.
Thank you for your cooperation on performing the tests to fins out why this is happening on your installation.
Ok, I got some of it set up. It does translate, and the view is displayed. This is without any conditionals. I noticed that it seems to have cache values that are not being updated. I am sure this is easily resolved. So it is translating. I will try to introduce the conditional next. I will let you know what I find out.
The issue was never resolved. The WPML, in conjunction with Toolset and conditionals, makes this solution unreliable and highly cumbersome. My client decided to take the language support out in favor of having an easy-to-update website.
