Problem:
We get this message in the WordPress dashboard:
"We detected that the product_type field was set incorrectly for some product translations. This happened because the product_type taxonomy was translated. You can fix this in the WooCommerce Multilingual & Multicurrency troubleshooting page"
Solution:
The WooCommerce product_type (Simple, Grouped, External, Variable) is set to "Not Translatable" by default.
It seems that this setting was changed on the site which causing this issue. Please try the following steps to fix this issue: 1. Create a full backup of the database and website. 2. Navigate to WPML > Settings > Taxonomies Translation. 3. Set the taxonomy
product_type
to "Not translatable". 4. Go to WooCommerce > WooCommerce Multilingual & Multicurrency > Settings > Troubleshooting. 5. Locate the "Fix product_type taxonomy terms" option and click Start.
Problem: The client was unable to translate the homepage. Solution: We recommend the following steps to resolve the issue: 1. Increase the memory limit. 2. Increase the value for max_input_vars in php.ini. These adjustments are necessary to meet the WPML minimum requirements. 3. Ensure that all components are up to date. 4. Conduct a test with only WPML active and a default WordPress theme, preferably in a testing environment, to determine if the issue is related to compatibility.
In this specific case, the client confirmed after those tasks, that the issue was caused by a different plugin and the ticket was closed by the client.
In case you experience similar issues, please let us know which plugin is causing the issue, so that we can try to recreate the issue and take further internal steps.
If this solution does not seem relevant to your situation, please open a new support ticket with us.
Problem: The client wants to know if there is any harm in switching between the Advanced Translation Editor and the Classic Translation Editor, as well as turning automatic translations on and off. Solution: We recommend reviewing our documentation on Switching from Classic to Advanced Translation Editor, which provides detailed guidance on this process. There is no harm in switching between the editors or toggling automatic translations on and off. However, if you need further assistance or clarification after reviewing the documentation, please don't hesitate to open a new support ticket in our support forum.
Problem: The client was experiencing issues with automatic translations where the queue was stuck and not processing any items. They initially attempted to translate the entire site, which consumed over 20,000 credits, and then tried to queue just 5 items, but the problem persisted. No errors were reported in the ATE error log, and the Translation Management page showed a spinner under the flag column that never completed.
Solution: We resolved the issue by repairing the corrupted ATE site keys. We recommend the client to restart the automatic translations from WPML->Translation Management, and it should now work without any issues.
If this solution does not seem relevant to your situation, please open a new support ticket with us.
Problem: The client reported that ACF link fields inside a custom block were not translatable. Solution: First, we verified that the 'Test link 2' field's value was set to 'Translate'. We found that the URL value was indeed showing for the translation when searched for. We recommended the client to refer to our documentation on how to translate URLs, shortcodes, and HTML attributes using the Advanced Translation Editor: https://wpml.org/faq/how-to-translate-urls-shortcodes-and-html-attributes-using-the-advanced-translation-editor/
Next, we resolved the issue by changing the field name of 'Button title' from 'button' to 'button_link', as 'button' or 'buttons' may be reserved words that could cause conflicts. Additionally, we upgraded to WPML version 4.6.9.
Problem:
Client was uploading logo in another language through media translation but on frontend, the logo on translated page was the same as the default language.
Solution: When using a logo through the customizer, theme options, or site settings, after translating the logo or image in WPML Media, it's also necessary to translate its image ID in String Translation. If you can't find the ID in String Translation, you should search for it in Admin Texts and then bring it into String Translation. For detailed instructions, please refer to our guide on how to translate theme options. Additionally, if you're having trouble finding the IDs, our documentation on finding and translating admin and settings strings may help.
If this solution doesn't look relevant to your issue, please don't hesitate to open a new support ticket in our support forum.
Problem: The client is unable to create the same slug for different language categories in WPML. Solution: 1. To achieve the same category slugs across different languages, you need to manually change the slugs for the secondary languages. You can follow the instructions provided in this support ticket.
2. It is also recommended to increase the WordPress memory limit to at least 128MB. You can do this by adding the following code to your
Problem: The client is unable to see the English version of their menu despite having translated the content and following WPML documentation. Solution: 1. Ensure that the site meets the minimum requirements for WPML. 2. Update the theme and plugins to the latest versions. 3. Follow the step-by-step instructions for translating menus provided in the WPML documentation. 4. Enable the "Adjust IDs for multilingual functionality" option from the WPML >> Languages page.
Problem: The client was unable to find certain strings for translation and was considering live assistance. After installing the WPML-WPForms Multilingual plugin, the issue was resolved. Solution: We recommended the following steps for clients experiencing similar issues:
1. Go to WPML -> String Translations.
2. Scroll to the bottom of the page and click the blue link Translate texts in admin screens ».
3. On the Admin Texts Translation page, search for the strings you want to translate.
4. Select the checkboxes next to the strings and click “Add to String Translation”.
5. Return to WPML -> String Translation to find the strings. For more detailed information, please refer to our documentation on Finding strings that don’t appear on the String Translation page.
Th client resolved the issue by installing WPForms Multilingual as he was using WPForms to create the forms with the strings needed to be translated.
If this solution doesn't look relevant to your issue, please open a new support ticket in our support forum.
Problem: The client is experiencing an issue where updating a product in a secondary language opens in the WordPress editor instead of the WPML Translation Editor. Even though the Translation Editor is activated, it gets disabled after editing, and the WordPress editor is enabled again. This problem does not occur with new products. Solution: The issue was resolved after running the WPML Troubleshooting options after creating a full backup of the database and website then navigating to WPML > Support > Troubleshooting and performing the following actions:
Clear the Cache in WPML
Remove ghost entries from the translation tables
Fix element_type collation
Fix WPML table collation
Synchronize local job ids with ATE jobs
Synchronize translators and translation managers with ATE
Set language information
Fix post type assignment for translations
If this solution does not apply to your case because it's outdated or not relevant, 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 you still need assistance, please open a new support ticket: WPML support forum.
Problem: The client needed to know if there is a way to update a translated string in the Translation Memory so that it automatically updates across all pages where it is used. Solution: We informed the client that an updated string will not automatically change on other pages. To apply the changes, the client should resend the pages containing the string to translation via WPML -> Translation Management. The client can send these pages to themselves as a local translator, even if they are marked as complete, by using the pencil icon. This action will trigger the update of the string on all pages without the need to edit each page individually.
If this solution does not seem relevant to your situation, please open a new support ticket with us.
Problem: The client is experiencing an issue where the name of a Custom Post Type (CPT) is not displaying correctly in breadcrumbs. Specifically, the translated version of the CPT is not showing up on the page.
Solution: We have identified this as a known issue related to the Advanced Custom Fields plugin version 6.1, which introduced the ability to register custom post types and custom taxonomies. Currently, WPML does not support translating the labels associated with these features. We have confirmed the problem exists by reproducing it on a test site.
Unfortunately, there is no workaround available at this time. However, we are actively working on a solution to support these new features in the Advanced Custom Fields plugin. We have escalated this matter and are monitoring it closely. While there is no estimated time of arrival for the fix, we recommend bookmarking the errata page at https://wpml.org/errata/advanced-custom-fields-6-1-custom-post-types-and-custom-taxonomies-labels-not-translatable-yet/ to stay updated or subscribe to the comments on that page for notifications.
Once the issue is resolved, we will provide an update through this ticket.
If this solution does not seem relevant to your situation, please do not hesitate to open a new support ticket at our support forum.
Problem: The client's website has a booking calendar in the footer that is sticky in the default language but loses its sticky functionality when switching to English. This issue also affects a button in the mobile version. Solution: We resolved the issue by regenerating the files and data for Elementor. If you're experiencing a similar problem with sticky elements not functioning correctly after translation, we recommend you try the following steps: 1. Go to your WordPress Dashboard. 2. Navigate to Elementor > Tools. 3. Click on the Regenerate Files & Data button. This action should restore the sticky functionality to your translated elements. If this solution doesn't seem relevant to your issue, please open a new support ticket with us.
Problem: The client is trying to allow other admin users to view and modify translations of Gravity Forms that were created and translated by their own user. However, each admin user only sees their own translations. Solution: We explained that the behavior the client is experiencing is expected. According to our documentation on setting up local translators and language pairs, once a translator completes a translation job, it cannot be taken by a second translator. If the client wants a different translator to edit and review the same translation, they need to resend the content for translation and assign it to that translator. As a workaround, we suggested that the admin users, who are also Translation Managers, can go to WPML -> Translation Management and resend the forms for translation. This will create new jobs in the system, allowing users to assign and open them. If this solution doesn't look relevant, please open a new support ticket.
Problem: The client has a Custom Post Field created with Advanced Custom Fields (ACF) and is experiencing a page that does not work. Solution: If you're experiencing a similar issue with a Custom Post Field using ACF and your page isn't working, we recommend you try the following workaround: 1. Visit the provided documentation page for a known issue with ACF. 2. Apply the workaround detailed in the documentation. You can find the workaround on this page: Advanced Custom Fields fatal error workaround.
If this solution doesn't look relevant to your issue, please open a new support ticket in our support forum.
This page includes support tickets that are resolved and documented. Looking for tickets that are “in progress”? Visit the complete support tickets archive
