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/.
