Background of the issue:
I am trying to translate a page using WPML and Crowdin integration. Although the translation is being sent to Crowdin and completed fully there, WPML is not receiving the translation. Here is the loom describing the issue: hidden link
Symptoms:
Strings aren't being sent back from Crowdin to WPML. I expected to see a fully translated page in German language, but instead, I got nothing.
Questions:
Why is WPML not receiving the completed translation from Crowdin?
How can I ensure that the translations are sent back to WPML correctly?
Please try my suggestion to use the troubleshooting section.
Meanwhile, I'm also consulting our Translation Service expert about your case.
If the troubleshooting section did not help resolve the problem, and you require further assistance, please share the access details to your site with me. I'm enabling a private message for the following reply.
Privacy and Security Policy
We have strict policies regarding privacy and access to your information. Please see: https://wpml.org/purchase/support-policy/privacy-and-security-when-providing-debug-information-for-support/ **IMPORTANT**
- - Please backup the site files and database before providing us access. --
-- If you have a staging site where the problem can be reproduced, it is better to share access to the staging site.--
Our Translation Service expert suggests the following.
He has checked the mentioned job and can confirm that the translation process itself appears to be working correctly. To help identify the issue, please follow these steps:
1. Open the page in the WPML Classic Translation Editor (CTE) and check whether the translation is visible there.
2. If the translation appears in the CTE but is still not showing on the front-end, try making a small change to the original post, saving it, and then checking again.
If the issue persists after these steps, feel free to share access credentials so we can investigate further. However, based on what we’ve seen so far, it’s likely that the issue is related to something on the website side rather than the translation job itself. I'm enabling a private message for the following reply. Privacy and Security Policy
We have strict policies regarding privacy and access to your information. Please see: https://wpml.org/purchase/support-policy/privacy-and-security-when-providing-debug-information-for-support/ **IMPORTANT**
- - Please backup the site files and database before providing us access. --
-- If you have a staging site where the problem can be reproduced, it is better to share access to the staging site.--
Hi, we are still experiencing the same issue after trying the options you recommended on the Troubleshooting section of the plugin.
But the issue is changed and now it seems that no content is being sent to Crowdin, and it does not seem like a Crowdin issue, since only the post title and URL are being sent to translation, without the post content.
I am sending you the screenshot of the Advanced Translation Editor, where it is visible which content is marked for translation.
I tried editing Custom XML Configuration in the plugin options and added:
<wpml-config>
<gutenberg-blocks>
<!-- Match all blocks in the eightshift-boilerplate namespace -->
<gutenberg-block type="eightshift-boilerplate/*" translate="1">
<!-- Catch all attribute names likely to contain translatable content -->
<key name="*Content" />
<key name="*Text" />
<key name="*Description" />
<key name="*Label" />
<key name="*Title" />
<key name="*Paragraph" />
<key name="*List" />
<key name="*Quote" />
</gutenberg-block>
</gutenberg-blocks>
</wpml-config>
Since my site is built on eightshift-boilerplate and all Gutenberg blocks have this prefix, and 99% of the content is in the key Content, so this should work.
Also, this worked before and seems like the new issue, on top of previous issue.
Do you have any suggestion on this?
Here is the example page I am trying to translate: hidden link
New threads created by Itamar and linked to this one are listed below:
We try to focus on one issue per ticket in our technical support forum. Otherwise, tickets can get cluttered and confusing for both users and supporters. I split this ticket to the new issue with the eightshift-boilerplate, and we will continue to help you with it here.
If you need further help with the Crowdin issue, please give us access to your site.
If you need further help with this, please share the access details to your site with me. I'm enabling a private message for the following reply. Privacy and Security Policy
We have strict policies regarding privacy and access to your information. Please see: https://wpml.org/purchase/support-policy/privacy-and-security-when-providing-debug-information-for-support/ **IMPORTANT**
- - Please backup the site files and database before providing us access. --
-- If you have a staging site where the problem can be reproduced, it is better to share access to the staging site.--
Please note that my weekend is Friday-Saturday, and I'll be able to continue to check this issue and help you on Sunday.
Regards,
Itamar.
Our Translation Service expert observed that you are using WPML's Advanced Translation Editor to edit translations done with the Crowdin Translation Service. This is wrong, as it is not possible to use the Advanced Translation Editor for translations coming from Translation Services. You should switch to the Classic Translation Editor when working with Translation Services. Then the content should appear for you to edit. You can switch this in WPML -> Settings -> Translation Editor. Please see the attached screenshot.
Additionally, our expert mentioned that the staging version provided appears to be an old backup, lacking the same settings and latest updates as the production website. For example, he can't see the translation job mentioned in the video you provided from your production website. Furthermore, when he attempted to verify the XLIFF file for the same job, he discovered that there was a significant amount of missing content, which suggests that some ACF or custom block configurations differ from the production one.
Thank you for your feedback. We will sync the production website with the staging website as soon as we can.
However, the main issue we are encountering is the same in the production and on staging. And exact same strings that get picked up in Crodwin get also picked up in WPML Advanced Translation Editor.
I am using Advanced Translation Editor on staging since I do not have the Crowdin integration on staging.
But regardless of using Crowdin or using Advanced Translation Editor, the issue is the same, for some posts all the strings get picked up, and for some almost none.
As I mentioned before:
For example, for this two posts all strings get picked up: hidden link hidden link
And for this two, only post title and URL gets picked up: hidden link hidden link
But you can also check different posts on our blog hidden link and try to translate them and reproduce the issue - to see that some posts get all strings picked up and some just the title and URL.
What we cannot figure out is why this would happen if the blocks in the editor are exactly the same, just the text and images differ.
Please try to find out why do they sometimes get picked up by Advanced Translation Editor and sometimes don't (because it is the same issue with Crowdin), as I am confident finding the solution to this will solve the issue.
Thanks for further explaining the issue and sending the example posts that work and that don't work. In light of this, can we define the problem as follows?
"Different posts made with the same Gutenberg custom blocks from the eightshift-boilerplate plugin get different results in WPML's Translation Editor. Sometimes the strings from the custom blocks show, and sometimes they are missing." Can you agree that this is the correct definition for the problem? Also, can we agree that it is not an issue with Crowdin Translation Service, as was initially suspected? And can we agree that all this relates to the same issue with the two tickets?
While checking hidden link">this post and attempting to translate it with the Advanced Translation Editor, I encountered a fatal error upon returning to the editing screen. Please see the attached screenshot. We need to check things in a more optimal and operational environment. Please synchronize everything with the production site and ensure that all updates are applied. Please let us know when this is done.
If needed, please allow me to take a copy of your site. For this, I must install a plugin like Duplicator or All In One Migration. Please let me know if you agree.
Please note that my weekend is Friday-Saturday, and I'll be able to continue to check this issue and help you on Sunday.
Ok, I see the error in BugSnag that happened while you were testing.
We did not have this issue while using translation editor, so not sure what happened, but as I can see the site is working fine, and translation editor also, besides picking up strings on mentioned posts.
Here are more details on the error:
Error
PHP Fatal Error: Uncaught TypeError: str_contains(): Argument #1 ($haystack) must be of type string, false given in /home/public_website/www/staging.productive.io/releases/20250612071655/wp-content/themes/productive/src/Enqueue/Blocks/EnqueueBlocks.php:80
Stack trace:
Also, I agree with your definition of the problem, and that it is the same problem in both tickets, so we can define it as you suggested.
We will sync the staging with production as soon as we can and get back to you to continue testing.
Regarding making copy of our site using Duplicator or similar plugin, we would like go through all other options before considering this.
Thanks for your assistance and let me get back to you.
I'm facing trouble completing the translations with the Advanced Translation Editor because you haven't registered the staging site on your WPML.org account at https://wpml.org/account/sites/. When I complete the translation, I'm getting a black page. I was willing to register it myself; however, you have not granted me full privileges, and I have no access to the plugins section. (Your site is a WordPress multisite installation.) Please register the staging site so I can continue to investigate the issue. Please give me one example of a post that has missing strings and one example of a post where things work as expected.
Important!
As we discussed, you are using custom Gutenberg Blocks by the eightshift-boilerplate. This plugin is not officially compatible with WPML, and it is possible that it lacks translation support for WPML. I mentioned this and explained what I can see is incorrect in the other ticket. For your convenience, I copied here my last reply from that ticket. Please see it below and try to apply the correct translation support for eightshift-boilerplate.
-----------------------------------------------------
Your eightshift-boilerplate XML code is incorrect.
The first thing I observe is the wildcard in the type attribute of the block.
You can't use wildcards for the type attribute.
You would need to declare each block type explicitly, like so:
<gutenberg-block type="eightshift-boilerplate/block-one" translate="1">
<!-- keys -->
</gutenberg-block>
<gutenberg-block type="eightshift-boilerplate/block-two" translate="1">
<!-- keys -->
</gutenberg-block>
<!-- and so on for each block type -->
Secondly, you can't use the wildcard (asterisk) before the key name.
This is wrong:
The staging site is registered on WPML.org as a development site. I am attaching a screenshot with the info it is registered.
I have also granted you super admin access to the network, so you now have access to the plugins section also (and everything else on the staging site).
I am sending again two examples of different posts, using same markup, just different text and images, and one is being translatable and other not:
For example, for this two posts all strings get picked up: hidden link hidden link
And for this two, only post title and URL gets picked up: hidden link hidden link
You can reproduce this on number of different posts on hidden link also.
Also, the part saying "Your eightshift-boilerplate XML code is incorrect." is no longer actual. The error was happening before I tried to fix it by adding "Custom XML Configuration" in WPML setting. This was one of suggestion to fix the issue, but since it did not work, I removed it after testing. If you go to WPML -> Setting -> Custom XML Configuration you can see there is nothing there.
Hope this helps and let me know if I can assist you any further in debugging the issue.
With this example you gave, I'm not seeing the problem. hidden link
I edit this page here: hidden link
And clicking the gear icon to get the Advanced Translation Editor here: hidden link
And I can see all, or at least most, of the content that needs translation. I'm not only seeing the title and URL. Please see the attached screenshot a-lot-of-content-to-translate.jpg.
I do see less content with this post: hidden link
However, upon editing both of those posts, I see the following message.
You need to translate this post manually because the field groups attached to it use different translation options.
I also wonder if the other missing content may come from different post types, such as Reusable Blocks, Customer Stories, and Career Stories. Please check that.
The message I mentioned above comes from our Advanced Multilingual. I tried to check ACF's field groups, but strangely, there is no admin menu to edit the field groups. I assume that the theme and the plugin you use by eightshift-boilerplate customize the use of ACF.
I want to restate that the eightshift-boilerplate theme and plugin are not compatible with WPML. They are also unknown to us. I have not found any other report about it in our forum or internal documentation. Currently, it appears that you are our only client using this theme and plugin. To set expectations, I must say that we might not be able to support it.
In conclusion, I'd say that you need to translate the post created with the eightshift-boilerplate system manually, as explained in the guide I shared with you. Hopefully this should work for yoy. However, please note that it will not enable you to translate the site manually. In WPML -> Translation Management -> Translation Jobs, you would need to delete any in-progress translations.
