We are experiencing a new issue with the WPML → Crowdin integration.
Summary of the Issue
When we send a page containing custom fields where the field value starts with “/” (first character), the field is not being sent to the translation service.
These fields do not appear in Crowdin, and they also do not appear in the source XLIFF file generated for the translation job.
Important Notes
• When using the WPML Translation Editor, the same fields appear correctly and can be translated.
• I tested several filters and confirmed that the string exists in WPML’s extraction pipeline, which means the issue happens somewhere in the proxy between WPML and the translation service (Crowdin).
• This behavior is new, it did not happen before.
At that time, the root cause was also related to the proxy layer between WPML and Crowdin.
This new issue appears to be of the same nature.
Expected Behavior
Fields should be sent to Crowdin for translation, even when the value begins with “/”.
Actual Behavior
Fields starting with “/” are ignored and excluded from the translation package.
Steps to Reproduce
1. Create a page with a custom field.
2. Set the field value to something that begins with “/”, e.g. /example-path.
3. Send the page for translation via Crowdin.
4. Observe that the field does not appear in Crowdin or in the generated XLIFF.
5. Perform the same test using WPML’s native editor — the field appears correctly.
Could you please investigate this issue on the WPML → Translation Service proxy layer?
It seems similar to the previous problem we faced and may require a similar fix.
This is Ahmed Mamdouh from the translation proxy team and I'll help you with this ticket.
Please provide me with the Project ID: Go to WPML -> Support -> Troubleshooting and press "Ctrl + f" and type "icl_translation_projects" and send me a screenshot.
Here’s an example of a job where you can see that the string is included in the source.
In the meantime, we’ve built a custom solution: we add an “=” before every field that starts with “/”, and then remove it in Crowdin in order to avoid this issue.
Languages: English (English )Spanish (Español )German (Deutsch )
Timezone: Europe/Vienna (GMT+02:00)
Hi,
Thank you for sharing the example of the jobs that are affected.
We investigated job 2377915 and reviewed the original XLIFF file that WPML sends to the Translation Proxy (TP). Based on the attached file, there is no text that starts with “/”.
To ensure we’re all looking at the same data, could you please check this hidden link">XLIFF file and confirm whether the content you expect to be translated is actually present in the file?
At this stage, it appears that the issue may be related to how WPML is extracting the content, rather than an issue on the Translation Proxy side. To verify this, we recommend the following steps:
1) Create a new test post using the same custom field.
2) Send this post to a local translator (not through a translation service).
3) Extract the generated XLIFF file and check whether WPML includes the expected content.
In parallel, we can try to replicate the scenario on a clean WordPress installation. I prepared a Sandbox installation here: hidden link.
These steps should help pinpoint the source of the issue and determine the best solution.
