Problem: If you're experiencing inconsistent string translations in your theme, where some strings are translated while others are not, and enabling 'Look for strings while pages are rendered' only temporarily solves the issue. Solution: We recommend checking and updating your theme's localization setup: 1. Ensure your theme's
3. Create a 'languages' folder in your theme directory. 4. Update the text domain in your theme's header code to match the one you've set, like so:
<?php _e('Zvani', 'blank') ?>:
After making these changes, scan and translate your theme again to check if the issue is resolved.
Please note that this solution might be outdated or not applicable to your specific case. If the problem persists, 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 needed, please open a new support ticket at WPML support forum for further assistance.
Problem: The client is experiencing an issue where the WooCommerce zoom.js does not work and the product images are oversized when switching languages using WPML. Solution: We have identified that the problem was caused by the custom related products settings not being copied to secondary languages. To fix this, please follow these steps: 1. Navigate to WPML → Settings → Custom Field Translations. 2. Click on Show system fields. 3. Search for _crp_related_ids and set it to Copy. 4. Save the changes. 5. After saving, update the product in the default language.
If this solution does not resolve your issue, or if it seems outdated or irrelevant to your 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 problem persists, please open a new support ticket at WPML support forum.
Problem: The client reported that WPML overwrites Gravity Form in the latest versions of Gravity Forms Multilingual, despite a previous workaround. They requested a new solution for this recurring issue. Solution: We revisited the previous workaround and found it still applicable. Here are the steps to implement the solution: 1. Open the file at /gravityforms-multilingual/inc/gravity-forms-multilingual.class.php. 2. On line 685, replace:
$snh = new GFML_String_Name_Helper();
with:
$snh = new GFML_String_Name_Helper();
// WPML workaround for compsupp-7768
$check = new \WPML\Utils\DebugBackTrace();
if ($check->is_class_function_in_call_stack('GFFormDisplay', 'process_form')) {
return $form;
}
3. Repeat the same replacement on line 822.
If this solution does not resolve your issue or seems outdated, we recommend opening a new support ticket. 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. For further assistance, visit our support forum at https://wpml.org/forums/.
Problem: The client is using WPML for automatic translations on their site but encounters issues where posts marked as translated do not display translations. Additionally, there are problems with translating custom post types (CPT) that use a custom table, and questions about the translation of strings on the front end and the associated costs. Solution: If you're experiencing issues with translations not appearing on posts or handling custom post types, we recommend the following steps: 1. Ensure that your CPT is registered according to WordPress Coding Standards and does not use a custom table, as WPML typically supports CPTs that follow these standards. 2. Check WPML > Settings > Custom Field translation to ensure that any custom fields used by your CPT are set to "Translate". This setting allows the fields to be translated along with the post in the WPML Translation Editor. 3. For translating custom post taxonomies, navigate to WPML > Taxonomy Translation. Taxonomies are usually translated once with the WPML Translation Editor while translating a post they are assigned to.
Unfortunately, there are no hooks available to trigger automatic translations directly after creating duplicates. However, you can manually trigger or queue translations after duplication.
If these steps do not resolve your issue or if the solution seems outdated or irrelevant 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 further assistance is needed, please open a new support ticket at WPML support forum.
Problem: The client was unable to automatically translate the content of the "Privacy Policy" page using WPML's "Translate Everything Automatically" feature. While the page title and permalink were translated, the content remained in the original language despite attempts to re-translate or delete and update the translations.
Solution: 1) We verified that the client should be listed as a translator in WPML > Translation Management > Translators, even if they are an admin, to ensure proper permissions for translation tasks.
2) We identified that the page had previously been translated using Gutenberg, which created a string package in WPML > Packages. Since the client was no longer using Gutenberg, this caused the system to copy content instead of translating it.
3) To resolve the issue, we navigated to WPML > Packages, located the package for the "Privacy Policy" page (which had an ID value of "3"), and deleted it. Afterward, we re-translated the page using the Advanced Translation Editor without using any additional credits, as the content had already been translated.
4) We explained that a string package with a name like [page builder name]-strings-[page id] indicates a page has been translated with a page builder, which in this case was Gutenberg. The issue likely occurred before the client installed the "classic editor" plugin.
If you're experiencing a similar issue, we recommend checking if you are listed as a translator and looking for any string packages related to page builders in WPML > Packages. If you find any, delete them and attempt to re-translate the page.
Please note that this solution might be irrelevant if it's outdated or not applicable to your case. If the issue persists, we highly recommend checking related 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.
Problem: The client needed to change the language code for Estonian from "ET" to "EE" in WPML and encountered issues with string translations not working for the custom "EE" language. Additionally, the client was unable to delete the original Estonian language to set the "Default locale" to "et" because it already existed in the database.
Solution: We advised the client to: 1. Re-add Estonian from the WPML language list. 2. Change the default locale of the re-added Estonian to any value other than "et". 3. Set the default locale for the custom Estonian ("EE") to "et". 4. Remove the WPML Estonian language. This process should not create errors and should allow the client to use the "EE" code for Estonian without issues with string translations.
Please note that this solution might be outdated or not applicable to your case. If you're experiencing similar issues and the provided solution does not resolve them, we highly recommend checking the related known issues, verifying the version of the permanent fix, and confirming that you have installed the latest versions of themes and plugins. If the problem persists, please open a new support ticket with us for further assistance.
Problem: The client is unable to see the text of an ACF link field within the Advanced Translation Editor. This issue is not limited to a specific field but affects all link fields. The client has the ACF group setting configured to 'Same fields across languages' and expects the link text to be translatable automatically, as suggested by the WPML documentation.
Solution: We have consulted with our ACF developers and confirmed that the 'Same fields across languages' option does not cover all scenarios, which is why the 'Expert' mode is available for clients to customize their ACF translation preferences. For the time being, to translate the ACF link fields, the client will need to switch to 'Expert' mode. Our developers are aware of this limitation, and it might be addressed in a future version of the ACFML plugin, but there is no confirmed timeline for this update.
If this solution does not seem relevant to your situation, please open a new support ticket with us.
