Problem: You are experiencing issues with WPML not translating some strings in emails and PDFs when using the MakeCommerce payment method. This occurs because the MakeCommerce plugin changes the site's locale from 'lv_LV' to 'lv' during the checkout process, which prevents the PDF Invoices & Packing Slips plugin from loading its translation files correctly. This is NOT a WPML issue; however, we provided a workaround. Solution: We recommend adding the following code snippet to your child theme's functions.php file or as a small MU plugin to ensure the correct locale is applied, allowing translations to load correctly:
/**
* Ensure text domain loaded for woocommerce-pdf-invoices-packing-slips
* which may fail when using MakeCommerce at checkout
*/
add_action( 'wpo_wcpdf_process_template', function(){
$domain = 'woocommerce-pdf-invoices-packing-slips';
$locale = determine_locale();
$locale = ( $locale == 'lv' ) ? 'lv_LV' : $locale;
if ( ! is_textdomain_loaded( $domain ) ){
$base = WP_LANG_DIR . "/wpml/{$domain}-{$locale}";
$phpfile = $base . ".l10n.php";
$mofile = $base . '.mo';
$file = $phpfile && file_exists($phpfile) ? $phpfile : ( file_exists($mofile) ? $mofile : null );
if ( $file ) {
load_textdomain( $domain, $file );
}
}
});
If this solution does not resolve the issue or seems irrelevant due to updates or different circumstances, 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.
Problem: The client was unable to see the translation engines and the 'Translate automatically' option in WPML -> Post Type Translations, and their WooCommerce products were not being translated. Solution: We recommended the following steps: 1. Navigate to WPML -> Translation Management -> Translation Tools tab. 2. Scroll down to find translation engines and enable/disable a few. 3. Go to WPML -> Settings to check if the translation engines are now visible. 4. If visible, proceed to WPML -> Translation Management and look for a switch to enable automatic translation. 5. If the issue persists, unregister and re-register WPML on the site by following these steps: - Go to the WPML registration page and click on 'Unregister WPML from this site'. - Remove the site from your WPML account. - Generate a new key and register the site again. 6. Double-check if the issue is resolved by ensuring the site can connect to WPML servers. 7. If problems continue, it might be related to a known issue which can be checked here: https://wpml.org/errata/admins-cannot-access-wpml-translation-management/
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 at WPML support forum.
Problem: The client was experiencing issues with partially translated emails in a WPML setup, where emails were half in English and half in Latvian despite updates to WPML, WordPress, WooCommerce, and having translations available for all content. Solution: 1. We recommended updating the WPML plugin and all add-ons to the latest version (4.7.1) to benefit from the latest bug fixes and improvements. Instructions for updating can be found at http://wpml.org/faq/install-wpml/. 2. We advised creating a full site backup before applying any changes. 3. We suggested applying a specific workaround for WooCommerce order update emails that may contain mixed language texts, detailed on the errata page at https://wpml.org/errata/wc-order-update-emails-may-contain-mixed-language-texts/. 4. We recommended deleting and re-translating specific strings via WPML -> String Translation. Detailed steps can be found at https://wpml.org/documentation/getting-started-guide/string-translation/finding-strings-that-dont-appear-on-the-string-translation-page/. 5. We conducted troubleshooting steps and ensured that the Elementor database was updated and the necessary strings were translated.
If this solution does not resolve your issue or seems outdated, 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: 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.
