[Resolved] Custom fields get overwritten by English values
This thread is resolved. Here is a description of the problem and solution.
Problem: The client is experiencing an issue where WPML replaces German strings with English strings in custom fields when a translator updates an existing post. This problem occurs across multiple post types and is suspected to be related to the Advanced Translation Editor.
Solution: We recommend setting the affected custom fields to "copy" so they are not editable in the translation editor and are always copied directly to the translation. This should prevent the fields from being overwritten. Here is a guide on managing custom field translations: Translating Custom Fields.
If the issue persists, consider disabling the WPML editor and continue using the manual method for translations. Alternatively, if using the Advanced Translation Editor, ensure that numerical values are correctly configured for translation by adding a specific code snippet to the functions.php file of your theme. More details can be found here: Translating Numbers.
If these solutions do not resolve the issue or if they seem outdated or irrelevant to your specific case, please check related known issues at https://wpml.org/known-issues/, verify the version of the permanent fix, and confirm that you have installed the latest versions of themes and plugins. We highly recommend opening a new support ticket for further assistance at WPML Support Forum.
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:
We use Meta Box to create our custom fields. Some fields contain a string that identifies a specific piece of content (e.g. a table or a map) in the correct language. So, when translating, we enter the German string in that field so that our website displays the German table. This worked fine, until mid November. When a translator is updating an existing post, which already contains the correct German value in such a field, WPML now replaces the German string with the English string. We have to manually correct it each time a translator has worked on a post. This problem occurs for multiple post types, but not consistently: it happens 90% of the time, sometimes the problem does not occur. I am not sure if the problem is caused by the update to WPML 4.6.13 in October, or the Advanced Translation Editor. We're not using the latest version of the Advanced Translation Editor, because that still has the other bug of randomly losing previously translated strings. So we use the previous version. We do not use the auto-translate feature. We don't have WooCommerce and I haven't seen this error: https://wpml.org/errata/php-error-wp-6-7-notice-function-_load_textdomain_just_in_time-was-called/. Please note that we cannot update WPML right now. We do that twice per year after extensive testing. Unfortunately this error was not found during those tests, but perhaps it has nothing to do with the plugin but only with the Advanced Translation Editor. This is causing us a lot of unproductive time and a sloppy frontend because it shows English content until we manually correct it.
Symptoms:
When a translator updates an existing post, WPML replaces the German string with the English string in custom fields. This issue occurs 90% of the time across multiple post types, causing unproductive time and a sloppy frontend with English content until manually corrected.
Questions:
How can the issue of custom fields being overwritten by English values be fixed?
Languages: English (English )Spanish (Español )Italian (Italiano )
Timezone: Europe/Rome (GMT+01:00)
Hello,
I'll help you get started while a supporter takes you case given you've waited too much for an answer already.
You mention that the VALUES are getting overwritten with translated values and that tells me it's been overwritten in the translation editor. It doesn't matter if it's the newest version or the older version of the Advanced Translation Editor because if the field is set to be translatable, then it will always appear. However it won't "randomly" translate to another language because that's not how the translation editor works. In order to translate anything, you either need manual intervention (someone translating the content, maybe unaware they are translating the values) or automatic translation.
Your comment leads me to believe it's a manual intervention. In this case, I'd suggest that since the values should remain as-is, you set such fields to "copy" so they don't appear in the translation editor and instead are always copied to the translation. this would probably solve the problem for you. Here's a quick guide about Custom fields translations in case you need it: https://wpml.org/documentation/getting-started-guide/translating-custom-fields/
If this doesn't work then please let me know what you did and how, so we can understand better what next steps to recommend.
Thanks for your suggestions. It doesn't look like a manual intervention after all the tests we did. Note that our setup and workflow have not changed.
For more insight, here's the format of the data we store in the field: "(var_name)number(var_name)".
So, for example: "(pf_number)20(pf_number)"
We need a separate value for each language, so setting the field to Copy won't solve this for us. If we have the above value for English, we'd have something like this for German: "(pf_number)22(pf_number)"
The problem is that in posts where we already had put in "(pf_number)22(pf_number)" a long time ago, WPML replaces it with the English value "(pf_number)20(pf_number)" while someone updates the translation.
Currently, the translation manager needs to go through all posts manually, after translators have updated them, in order to correct these field values.
I believe the values in German are and where set manually since the Advanced translation editor does not show numbers for translation, so probably that is how you have added themthem or still are adding them. If yes, then this is expected and any manually added content will be deleted when the default language is updated/translated via the Advanced translation editor.
So, you have 2 solutions on how can you achieve this, so the custom field is not being overwritten:
1) Make sure the custom field is set to Translate and disable WPML editor and continue to use the Manual method further for your translations:
2) Use the Advanced translation editor and re-translate numbers via this editor, and next time it will not be overwritten. However, if you want to translate the numerical values from the ATE, you'll need to add the following code snippet to the functions.php file of your theme first.
Can you please share a video of an example so I can clearly see the issue:
- disable object cache
- make a small change to the default language page and translate, save
- Make sure numbers and content is translated
- Make a small change again in the default language page and translate, let me know if the issue still happens?
If this does then it might be some bug and we will check it out, if it doesn't happen, it could be that it was translated differently in the first place and not via the WPML ATE editor.
Thank you. I will do so once the problem occurs again. Magically, today was the first time it didn't happen in a batch of 12 post translations.
We can rule out that translations were done outside the WPML ATE editor. Nobody except myself knows how to do that, and I rarely translate and don't do it like that either.
