Problem: You are trying to translate a string from Hebrew to English using the
1
wpml_translate_single_string
hook in WPML, but it fails to translate into the website's default language (English), while it successfully translates into Russian. Solution: The
1
wpml_translate_single_string
hook does not translate into the default language because WPML assumes the string in the default language is the original value and does not store translations for it. To retrieve a translation based on the current language, use the default language string as the source and pass the current language as the target:
This method uses the default language string ('Subject en') as the source, and WPML looks up the appropriate translation for the current language. For further understanding, you might find these guides helpful:
If this solution does not apply to your case, or if it seems outdated, we recommend opening a new support ticket. We also highly suggest 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. For further assistance, please visit our support forum: WPML Support Forum.
Problem: The client was facing an issue where translated posts set to draft were still appearing in the frontend category listing. Despite using WPML's troubleshooting options like 'Synchronize post taxonomies' and 'Fix post type assignment', the draft posts remained visible. Solution: The client discovered that the issue was related to the custom category.php file not filtering out posts based on their draft status and language settings. By debugging the category.php template, it was found that posts in one language were displaying in another language's listing even if they didn't exist in that language on the backend. The client resolved this by setting a filter/condition in the category.php to only display posts in their respective languages.
If you're experiencing a similar issue, we recommend checking your theme's category.php file for proper filtering of post statuses and languages. Additionally, ensure that your WPML plugins are up to date by visiting WPML Downloads.
Please note that this solution might be irrelevant if it's outdated or not applicable 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 issue persists, please open a new support ticket at WPML Support Forum.
Problem: The client has a multisite WordPress installation and wants all the subsites to share the same WPML tables instead of having their own per-site prefixes. They are looking for a way to configure WPML to share the same tables across all subsites and inquire if there is a setting to force a specific prefix. Solution: We explained that sharing WPML tables across all subsites in a multisite installation is not possible with the current setup of WordPress and WPML. This would require significant custom adjustments both to WPML and WordPress itself. For such custom coding, we recommend consulting with WPML contractors who are familiar with WPML's inner workings. You can find a list of contractors here: https://wpml.org/contractors/
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 you still need assistance, please open a new support ticket at WPML support forum.
Problem: The client's website footer translated into Spanish displays incorrect styling compared to the German and Dutch versions. Solution: We recommend adding the following custom CSS to address the styling issues in the Spanish footer. Navigate to WP > Appearance > Customize > Additional CSS and insert:
This solution might not be relevant if it's outdated or not applicable 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 issue persists, please open a new support ticket at WPML support forum.
Problem: After duplicating products and importing translated content via WP All Export and Google Sheets, the products still display as duplicates in the admin area with a message indicating they are maintained by WPML. This could potentially overwrite the translations if the original product is edited. Solution: This behavior is expected because WP All Export does not modify the post status in the postmeta table, which means imported products remain marked as duplicates. To resolve this, you can manually set each product to 'translate independently' by clicking the respective button in the WPML interface. Alternatively, you can attempt to remove the
1
_icl_lang_duplicate_of
keys using WP All Import, which might change their status to independent translations. Detailed steps for this process can be found here. Ensure you back up your site before making these changes.
If this solution does not apply to your situation, or if it seems outdated, we recommend opening a new support ticket. We also advise 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. For further assistance, please visit our support forum.
Problem: You have a bilingual site in English and Arabic, with English as the default language. While creating posts in Arabic, you want the taxonomies to display in English in the backend, but they currently appear in Arabic. Solution: We currently do not support changing the backend language for taxonomy terms while maintaining different front-end translations directly through WPML settings. However, you can achieve this by implementing a custom filter in your theme's functions.php file. Here is a sample code you might consider:
This code checks if you are in the admin area and modifies the term names to their English versions for specific taxonomies. Note that you might need to define the function
1
get_english_version
to fetch the English names based on term IDs. For further customization, you may consider hiring a developer from our contractors' page.
If this solution does not apply to your case, or if it seems outdated, please check the related known issues and confirm that you have installed the latest versions of themes and plugins. If the issue persists, we highly recommend opening a new support ticket for personalized assistance.
Problem: Der Kunde kann den Übersetzungseditor nicht verwenden, da er sich beim Laden aufhängt. Es wird ein Fehler angezeigt: "ATE Server Communication: Unable to authenticate". Der Fehler wurde durch eine spezifische Anpassung in der functions.php des Themes verursacht, die das eingebaute jQuery von WordPress deregistriert und es im Footer neu registriert, wodurch jQuery im WP-Admin-Bereich zu spät oder gar nicht geladen wird. Solution: Wir empfehlen, das Theme vorübergehend auf ein Standard-Theme zu wechseln, um zu überprüfen, ob das Problem weiterhin besteht. Wenn der Übersetzungseditor unter dem Standard-Theme funktioniert, liegt das Problem wahrscheinlich an der spezifischen Anpassung in der functions.php Ihres aktuellen Themes. Entfernen Sie den Code, der jQuery deregistriert und neu registriert, oder kommentieren Sie ihn aus:
Diese Lösung könnte veraltet sein oder auf Ihren Fall nicht zutreffen. Wir empfehlen Ihnen, die bekannten Probleme zu überprüfen, die Version der dauerhaften Lösung zu verifizieren und zu bestätigen, dass Sie die neuesten Versionen von Themes und Plugins installiert haben. Sollte das Problem weiterhin bestehen, zögern Sie nicht, ein neues Support-Ticket zu eröffnen. Besuchen Sie dazu unser Support-Forum.
