Problem: The client reported that a string at the bottom of BetterDocs pages was not showing the translation, despite the translation being in place and having worked previously.
Solution: We recommended that the client should first update the WPML plugin and add-ons to the latest version to ensure they have all the latest bug fixes and improvements. We provided instructions for updating and emphasized the importance of backing up the database before proceeding.
If the issue persisted after updating, we suggested the following steps: 1. Go to WPML → String Translation. 2. Enable the option "Look for strings while pages are rendered". 3. Navigate to the page where untranslated strings are displayed. 4. Return to WPML → String Translation and check if the string has been registered. 5. If found, translate the string.
We also provided a link to the documentation for finding and translating strings that do not appear on the String Translation page:
Problem: The client is experiencing an issue where the homepage shows a blank page when switching the default language to English, despite having set the Language URL format to different languages in directories and creating a root page in WPML settings.
Solution: We recommend trying to replicate the issue in a sandbox environment. If the problem persists, please follow these steps: 1. Set up the sandbox with the same WPML settings. 2. Translate the homepage from Lithuanian to English. 3. Attempt to switch the default language to English. 4. If a blank page appears, inform us and provide the steps taken to recreate the issue.
If this solution does not seem relevant to your situation, please open a new support ticket with us, and we will be happy to assist you further.
Problem: The client was unable to access WPML Translation Management and encountered a blank page. Additionally, there was a warning indicating that the default language, English, must be mapped to a supported language for automatic translation, but there was no apparent way to fix this on the Edit Languages page. Solution: We identified that the issue was due to the site migration from another site, and a necessary migration banner in WPML > Translation Management was not displayed because it was removed by the Traveler theme and child theme. To resolve this: 1. Switch to a standard WordPress theme, such as Twenty Twenty-One. 2. The migration banner should now appear in WPML > Translation Management. 3. Choose 'Yes' (copy) or 'No' (move) to proceed with using WPML. For further guidance, refer to our documentation on Using Advanced Translation Editor when you move or use a copy of your site.
Problem: The client is trying to get the breadcrumb for a Custom Post Type (CPT) 'Projecten' to translate to 'Projects' on English project pages using the JetBlocks plugin. Additionally, there are inconsistencies in the URL structure for projects when accessed in different ways. Solution: For the breadcrumb translation issue: 1. We navigated to "Plugins > Plugin File Editor." 2. Selected the "JetBlocks for Elementor" plugin and accessed the "cherry-x-breadcrumbs.php" file in the 'jet-blocks/includes/modules/breadcrumbs/' folder. 3. Inserted the following code snippet after line 552:
This code enables the display of the translated CPT in the breadcrumb.
For the URL structure issue, we advised the client to translate the posts within the 'Projecten' post type into English to ensure the correct slug 'Projects' appears on the English pages.
Problem: Client was experiencing a fatal error (Fatal error: Uncaught Error: Call to a member function get_source_language_code()), when trying to translate a page automatically.
Solution:
There seemed to be the problem with page's records in DB, perhaps corrupted, which we fixed with the following steps:
1. Open the product for editing in the default language. 2. Switch to the target language using the top admin language bar. 3. Click "Copy content from [default language]" and then save. 4. Repeat these steps for each language you want to translate to. 5. Go to WPML -> Translation Management and send the product for automatic translation again.
Problem:
Client is attempting to redirect users to the appropriate language-specific login page when clicking "Login" in the Header Navigation Menu of the BuddyBoss theme. The default login URL always points to wp-login.php and does not account for different languages.
Solution:
We recommend saving the current language to a variable using the wpml_current_language hook, which returns the language code of the active language. Then, set conditions for each language to change the returned URL accordingly.
// Get the current language code
$current_language = apply_filters('wpml_current_language', null);
// Check if the current language is English
if ($current_language == 'en') {
// Redirect to the English login page
} else {
// Redirect to the login page of other languages
}
If this solution does not seem relevant to your issue, please feel free to open a new support ticket in the WPML support forum.
Problem: The client is experiencing an issue where categories and products translated using automated translations with prepaid credits are not appearing on the frontend of their multilingual WooCommerce site. Solution: 1. We performed standard WooCommerce Multilingual troubleshooting actions without resolving the issue. 2. We recommended deactivating third-party plugins to check for conflicts, leaving only WPML and necessary plugins active. 3. If the problem persisted, we suggested switching to a default WordPress theme to test if the theme was causing the issue. 4. Upon testing in a staging environment, we identified the conflict with the 'WooCommerce Product Search' plugin. Deactivating this plugin resolved the issue, and the categories displayed correctly.
If this solution does not seem relevant to your situation, please feel free to open a new support ticket with us.
Problem: The client is experiencing an issue where the language switcher is not appearing after deleting some old pages and approving translations. The client is also unsure how to translate the Home page using the OnePress theme. Solution: We recommend checking if the translated version of the Home page exists and is published. This can be done by editing the Home page in the default language, then using the language switcher in the top admin bar to switch to the secondary language. Verify if the page is published or translated. Once the page is published, the language switcher should appear allowing you to switch between languages. If this solution does not seem relevant to your issue, please open a new support ticket with us.
Problem: The client is experiencing an issue where the synchronization between products is not working as expected. When the status of a product is changed from published to draft in one language, the translated version of the product does not reflect this change and remains published. Solution: We explained that this is the expected behavior in WPML. To change the status of a translated product, the client should manually switch to the desired language by clicking on the flag in the top-bar and then edit the product status in that language. If this solution does not seem relevant to your situation, please open a new support ticket with us.
Problem: The client is trying to edit the English translation of their homepage built with Elementor but is encountering issues. Solution: We noticed that the client's website does not meet the minimum memory requirements for WPML to function properly. We recommend increasing the WordPress memory limit. To do this, add the following lines to the
For more information on how to increase the memory allocated to PHP, please visit the following link: Editing wp-config.php After increasing the memory limit, we suggest making a small change to the original content and then updating the translation. If this solution does not resolve the issue, please open a new support ticket with us.
Problem: The client wants to disable a specific option (not detailed in the summary) and is currently importing products in Greek via XML with WP All Import and then translating them into Bulgarian. Solution: We recommend two alternative methods to the client's current process of duplicating and then translating products: 1. Use automatic translation to bulk translate products. This method incurs additional costs, and it's important to ensure that the products are set as "translatable" under WPML Settings. More information on automatic translation can be found here: Automatic Translation Documentation. 2. Manually translate products without duplicating them by using the WPML Translation Editor. This can be done by going to the products list and clicking on the "+" sign in the languages column. It's essential to have "Languages" checked under screen options at the top of the page. If these solutions do not seem relevant, we encourage the client to open a new support ticket for further assistance. Assistance can be sought at the WPML Support Forum.
Problem: The client is unable to display translated Advanced Custom Fields (ACF) posts on their site. They only see the Danish posts and not the translated ones. The issue might be related to the query in Elementor, as the translated tags are not visible in Elementor. The client attempted to add
define( 'ACFML_HIDE_FIELD_ANNOTATIONS', true );
to the wp-config file, but it resulted in strange field names without solving the issue.
Solution: We suggested that the client should assign distinct names to the tags and categories for the English language content. Specifically, by adding "-en" to the tags, and then applying this filter to check if it functions correctly. We provided a link for the client to edit the page in Elementor: https://fiberlan.dk/wp-admin/post.php?post=11679&action=elementor.
In a follow-up, we advised the client to copy and paste the tag as demonstrated in a screen recording we provided. We also reminded the client to refresh the Elementor editor or clear the Elementor and browser cache if the tags still did not appear after editing.
If this solution does not seem relevant, please do not hesitate to open a new support ticket with us for further assistance: WPML support forum.
Problem: The client's website is in three languages (FR, Dutch, EN), and they noticed that the "Next" and "Previous" buttons at the end of their articles were not translated into Dutch, despite the strings being translated in the WPML String Translation. Solution: We found that these strings are part of an Elementor template. We recommend translating the Elementor template directly. After translating the template on the client's test site, the issue was resolved. If this solution doesn't look relevant to your issue, please open a new support ticket with us.
Problem: The client needed to transfer credits from an old site to a new one but had no access to the old site and was unable to see the credits on their account after deleting the old site's key. Solution: We moved the 90,000 credits from the old site to the client's WPML.org account. The client can now assign these credits to the new site or any other registered site. If this solution doesn't look relevant to your issue, please open a new support ticket.
Problem: The client's Norwegian language (language code "nb") disappeared from their website after updating WPML. The update prompted a message about missing records in the languages tables. Despite applying a fix with
icl_sitepress_activate()
, issues persisted, including the disappearance of the Norwegian language flag and the appearance of an unrelated Norwegian language option. A subsequent website update and CloudFlare cache busting resulted in the complete loss of the Norwegian language. The client's translations are associated with the 'nb' code, which is not recognized by WPML, and manually changing to 'no' is not an option due to official deprecation and link structure concerns.
Solution: We recommend the following steps: 1. Navigate to WPML > Support > Troubleshooting. 2. Use the "reinstall and repopulate language table" option, which will delete the Norwegian custom language. 3. Re-add a custom language with the language code 'nb', set "nb" as the default locale, and save. 4. Add the built-in Norwegian language, change the default locale to 'nb_SE', and add 'nb_NO' as the default locale for the custom Norwegian. 5. Remove the built-in Norwegian language. This workflow should ensure that translations are visible as expected.
If this solution does not seem relevant to your situation, please open a new support ticket with us.
This page includes support tickets that are resolved and documented. Looking for tickets that are “in progress”? Visit the complete support tickets archive
