[Resolved] String Translation no longer functioning during save_post
This thread is resolved. Here is a description of the problem and solution.
Problem: You are encountering an issue where gettext functions used in an export mechanism on post save are not utilizing String Translation. This occurs despite using an identical template that works correctly elsewhere. The issue is visible when default English values for CTAs appear, suggesting that translations are not being applied. Solution: We have determined that the issues you are experiencing are due to errors in the custom code within the 'hope_ind-plugin'. Since this falls outside our standard support policy, we recommend consulting with a professional. If you need help troubleshooting or fixing the custom code, consider reaching out to a certified WPML contractor for specialized assistance.
Please note that this solution might be outdated or not applicable to your specific case. We highly recommend checking related known issues at https://wpml.org/known-issues/, verifying the version of the permanent fix, and confirming that you have installed the latest versions of themes and plugins. If the issue persists, please open a new support ticket.
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.
Background of the issue:
I am trying to figure out why gettext functions used in an export mechanism on post save don't appear to be using String Translation. Our export uses an identical template to create the page and invokes the same gettext functions, except this runs as a hook for save_post. Link to a page where the issue can be seen: hidden link. I expected to see CTAs labelled like they are in hidden link. Adding _load_textdomain_just_in_time('hope_industrial') to the beginning of the hook invocation did not help.
Symptoms:
The default English values for those CTAs appear, as if the translations did not exist.
Questions:
Why are the gettext functions not using String Translation during post save?
How can I ensure the translations are applied correctly in the export mechanism?
Languages: English (English )Spanish (Español )German (Deutsch )
Timezone: Europe/Madrid (GMT+02:00)
Hi,
Apologies for the delay in responding; we’re currently experiencing a higher volume of support requests.
Could you please provide the exact code you used to reproduce the issue? Alternatively, it would be even better if you could replicate the problem in this isolated sandbox environment: hidden link.
I suspect the issue might be related to your use of WPML version 4.6.15, which includes adjustments for WordPress 6.7 changes, as described here: PHP Error WP 6.7 Notice.
If possible, you could also test this on a staging environment with WordPress 6.7 (currently, you are using version 6.5.5) to see if the issue persists.
As instructed, I updated a staging version of the site to WP 6.7.1 and ran the export (which runs during the "acf/save_post" hook) for a page in Italian, and error_log()'ged calls to gettext functions (specifically, __() ) during the process. In all cases, every string returned the English default and not the Italian, which definitely exists, and would have been contextually correct as I also logged the value of ICL_LANGUAGE_CODE at that moment.
I've never received the error message you linked to, either, probably because I'm not making the call to _load_textdomain_just_in_time until the acf/save_post hook (so not during init).
If you need admin access to a staging server or logs, please let me know so I can go about acquiring permission from the client.
Languages: English (English )Spanish (Español )German (Deutsch )
Timezone: Europe/Madrid (GMT+02:00)
Thanks for the info:
1) Please give us access to your staging environment where we can isolate and reproduce the issue. This will help us analyze the problem in a controlled setting.
2) Please share the specific code related to your acf/save_post implementation. Additionally, clarify what your export functionality is doing—specifically, what data you are exporting and how.
3) Please note that ICL_LANGUAGE_CODE is deprecated and not recommended for use. This constant is defined only when WPML loads and reflects the language detected during initialization. For instance, it won’t update dynamically, such as when switching languages via AJAX, which can lead to incorrect values. Instead, we recommend using the wpml_current_language filter for reliable language detection.
Please also note that our support for custom coding is limited. If the issue is determined not to be caused by WPML itself, we may not be able to provide a complete solution. However, we will do our best to ensure that there is no bug on our side and guide you in the right direction.
Languages: English (English )Spanish (Español )German (Deutsch )
Timezone: Europe/Madrid (GMT+02:00)
Hi,
Thank you for providing access. To make debugging easier for our team, it would be best if you could install a File Manager plugin on the staging site. This approach avoids the need to manage individual SSH keys. Additionally, the example product has been saved—could you please share the log for our review?
Languages: English (English )Spanish (Español )German (Deutsch )
Timezone: Europe/Madrid (GMT+02:00)
Thank you! We’ve reviewed it but couldn’t identify any specific reason for this issue. Could you please provide a duplicator copy with the full code so we can reproduce the problem in a debugger? This is essential, as we also couldn’t find anything in the correct code that registers the custom post type, for instance.
This should just be a normal page being saved (with a specific template type), so custom post types should not be in play here. There is a function in that file that deals with a separate CPT but it's not being involved in this issue at this time.
In terms of duplication, what do you require? I'll need to get permission from the client to share.
I'm ready to share three files:
hope-industrial-new_wpml_2025-01-28T14-55-25_UTC_code.tar.gz
hope-industrial-new_wpml_2025-01-28T14-55-25_UTC_database.sql.gz
hope-industrial-new_wpml_2025-01-28T14-55-25_UTC_files.tar.gz (the contents of /wp-content/uploads)
Let me know the Google account I should grant access to and I'll get that sent over right away.
Another note - please make sure your testing environment domain includes the word "test", "stage", or "local" - this makes sure the export function does not update live data!
