Problem: The client was unable to update to WPML version 4.7 and faced issues with their glossary disappearing after attempting updates and key changes in a staging environment. The glossary was not stored locally but on WPML's servers, and the client was concerned about the loss of translations and glossary entries. Solution: We advised the client to ensure they were not using the beta channel for updates and to switch to the production channel to check for updates. If necessary, the update could be manually downloaded from the WPML.org account. For the glossary issue, we confirmed that glossary entries and automatic translations are stored under an ATE (Advanced Translation Editor) account on WPML's servers, not linked to the WPML registration key. We recommended ensuring that both staging and production environments are connected to the same ATE account to avoid issues like missing glossary entries or unsynced translations. If discrepancies continue, we suggested re-registering the WPML key without affecting existing translations or glossaries, as these are managed separately through the ATE account. For detailed steps on managing glossary entries, please refer to this documentation.
If this solution does not resolve your issue, or if it 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 problems persist, please open a new support ticket at WPML support forum.
If this solution does not apply to your case, or if it 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. Should you need further assistance, please open a new support ticket at WPML support forum.
Problem: The client is experiencing an issue where translations are inserting unwanted tags in the HTML across the website, which are not present in the original English text. This issue is visible on the homepage and menu, and there are [returns] in the backend text editor that should not be there.
Solution: We have consulted with the developers of the Advanced Translation Editor (ATE), and they provided the following insights and suggestions: 1. When segments are manually joined, they are combined with a \n (e.g., joining phrase1 and phrase2 results in phrase1\nphrase2). 2. For the pages in question, it appears the segments may have been manually joined. To address this, they suggest: - Unjoining the segments, which should resolve the issue. - Alternatively, updating the translations using the previously recommended solution.
Currently, there is no batch solution to address this issue comprehensively. The only option available is to fix it manually. Our developers are considering creating a script to automate the process, but it will require time as it may introduce additional complications.
If this solution does not apply to your case, or if it 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 issue persists, please open a new support ticket at WPML support forum for further assistance.
Problem: You are facing an issue where the 'review translations' function does not display any results despite indicating there are over 600 reviews pending. This problem arises while managing translations for a large number of pages/posts across multiple languages, requiring a simple system for non-developer international team members to use. Solution: First, ensure that you have correctly added the language pairs. This setup is crucial for the translations to appear in the review queue. For guidance on setting up language pairs, refer to the documentation here: https://wpml.org/documentation/getting-started-guide/language-setup/ Once the language pairs are set, the translations should be visible in the translations queue, ready for review. If you continue to experience issues or find this solution outdated or irrelevant to your specific case, we recommend opening a new support ticket. Additionally, always 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. If further assistance is needed, please contact us through the WPML support forum: https://wpml.org/forums/forum/english-support/
Problem: You are experiencing double charging for translations on both production and staging sites, despite the expectation that translations should not be charged again as per documentation. Solution: The issue occurred because the Translation Memory was not updated in time, leading to double charges. We have refunded you 80k credits to address this error. To prevent future occurrences, we recommend translating content directly on the production site and setting them to be reviewed before publishing via WPML > Settings. If you choose to translate on the staging site, please wait at least 5 minutes before sending the same content for translation on the production site.
If this solution does not resolve your issue or seems outdated, 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 if the problem persists. You can do so at WPML support forum.
Problem: The client is experiencing an issue with Jet Engine listings where the listing grid is mixing languages. When clicking on a Dutch version of a listing, it redirects to the English version. The issue is also observed with slugs, where the Dutch version uses the postname and the English version uses the post ID.
Solution: We have identified that the problem is due to the current Custom Query used for listing the posts. The query is incorrectly assuming that the
term_taxonomy_id
and
term_id
in the term relationships and terms table always match, which is not the case and can lead to fetching incorrect values and retrieving the wrong language.
To resolve this, we recommend adjusting the query so that it does not solely rely on
terms.term_id
for fetching values.
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.
