Problem: The client is trying to translate customized fields using WPML but encounters an issue where the translations do not appear on the frontend. The client used a custom hook and registered labels to WPML, translating them successfully. However, despite following documentation and using code examples, the translations are not visible on the frontend. Solution: 1. Ensure the text domain is correct. According to WordPress documentation, the text domain must use dashes, be lowercase, and have no spaces. 2. When using variables in translated strings, use the
printf()
function instead of echoing the variable directly. For example, change:
<p id="popup-title"><?= $popuptitle ?></p>
to:
<p id="popup-title"><?php echo __('Subscribe Now, Save 10%', 'storefront') ?></p>
After making these changes, re-scan the strings in the child theme, translate the string, and check if the translation displays on the frontend. 3. If using a custom text domain like "popup", register it with the following function in your theme's
If this solution does not resolve your issue or 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.
Problem: You are experiencing an issue where WPML is not translating the WPBakery Page Builder templates correctly, and the translations are not appearing on the live website despite following the documentation at https://wpml.org/documentation/plugins-compatibility/how-to-build-multilingual-sites-with-wpbakery-page-builder-and-wpml/. Solution: 1. Ensure that you are using the WPML Translation Editor to translate your content. Post types such as pages, posts, and page builder content cannot be translated directly at WPML > String Translation. 2. Go to WPML > Settings > Post Type Translation and set the WPBakery Templates to "Translatable - only show translated items". 3. Translate the templates using the WPML Translation Editor, similar to how you would translate pages and posts. 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. Additionally, you can open a new support ticket for further assistance at WPML support forum.
Problem: The client created a custom post type with associated custom fields using ACF, translated via WPML. They then used Ninja Table to display these fields. While it works in French, in English, the custom field values still appear in French, and the shortcodes added to the table do not display any content.
Solution: We recommended modifying the function to dynamically retrieve the post type of the
$post_id
instead of hardcoding it. We also suggested adding error handling for missing fields and allowing dynamic shortcode attributes. Here is the revised code:
// Function to get translated ACF fields using WPML
function get_translated_acf_fields($post_id, $language_code = null) {
if (!$language_code) {
$language_code = apply_filters('wpml_current_language', null);
}
$translated_post_id = apply_filters('wpml_object_id', $post_id, get_post_type($post_id), false, $language_code);
if (!$translated_post_id) {
return null;
}
$fields = array(
'ville' => get_field('ville', $translated_post_id),
'publics' => get_field('publics', $translated_post_id),
'programmes' => get_field('programmes', $translated_post_id),
);
return $fields;
}
add_shortcode('ville_field', 'display_ville_field');
add_shortcode('publics_field', 'display_publics_field');
add_shortcode('programmes_field', 'display_programmes_field');
Additionally, we suggested testing the code without Ninja Table first and ensuring that Ninja Table is set as "Translatable" in WPML > Settings > Post Type Translation, then translating the tables and using their respective shortcodes in each language.
If this solution does not resolve your issue or seems irrelevant due to updates or differences in 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 further assistance is needed, please open a new support ticket at WPML support forum.
Problema: Utilizzi Gravity Form con l'addon ufficiale per creare articoli su WordPress in un sito multilingua (italiano, inglese, francese), ma quando un form viene compilato in inglese, l'articolo risultante viene creato in inglese anziché in italiano, la lingua base del sito. Soluzione: Questo è il comportamento atteso di Gravity Form quando utilizzato in un contesto multilingua. Una possibile soluzione è non tradurre il form o impostare il tipo di post risultante come non traducibile. Questo potrebbe far sì che gli articoli vengano creati sempre in italiano, indipendentemente dalla lingua in cui il form è stato compilato. Se questa soluzione non dovesse essere adeguata, l'unica alternativa sarebbe creare del codice personalizzato, che però non possiamo fornire.
Se questa soluzione non risolve il problema o se è inapplicabile al tuo caso, ti consigliamo di verificare i problemi noti e di assicurarti di avere installato le versioni più recenti dei temi e dei plugin. Se il problema persiste, ti invitiamo a aprire un nuovo ticket di supporto.
Problem: The client wants to change the URL structure to include the category slug, but only for the Norwegian language on their multilingual site. They are using WPML and currently have a different structure for Danish. Solution: We have determined that it is not possible to have different URL structures for each language when using WPML, as the content needs to be linked properly across languages. Additionally, attempting to force this change through code modifications is likely to cause issues and is not recommended.
If this solution does not resolve your issue, or if it seems outdated or irrelevant to your specific case, we encourage you to open a new support ticket. We also 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. For further assistance, please visit our support forum at https://wpml.org/forums/.
Problem: If you're using the WordPress Focal Point plugin to set focal points on images and have noticed that the 'bg_pos_desktop' meta field is not being copied to new translations despite being set to 'Copy', you might be facing a compatibility issue. Solution: First, ensure that you can view the meta field within the media when editing it in the backend. Remember that media IDs differ per language, which might affect the copying process. Unfortunately, the Image Background Focus Position plugin is not officially compatible with WPML. We recommend contacting the plugin author to join our Compatibility program to facilitate compatibility. Meanwhile, you can manually adjust the focal point by: 1. Going to the Media Library. 2. Using the language switcher at the top to switch to the secondary language. 3. Editing the media and adding a focal point manually. This workaround allows you to set a focal point that could be the same or different per language. For a visual guide on these steps, you can watch this screencast: Workaround steps.
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 do not hesitate to open a new support ticket at WPML support forum.
Problem: The client is using WPML and SearchWP on their development site and wants to search for text and return posts in the current language only. However, the search returns posts in all languages. Solution: We recommend modifying the search query to ensure it filters results based on the current language. Here's a step-by-step guide:
// Ensure you have WPML's language set up
$current_language = apply_filters('wpml_current_language', null);
// Arguments for the query
$args = array(
'post_type' => $post_type,
'posts_per_page' => $posts_per_page,
'post_status' => 'publish',
'orderby' => $params['orderby'] ?? 'date',
'order' => $params['order'] ?? 'DESC',
's' => $params['search'],
'paged' => $paged,
'suppress_filters' => false,
// This ensures WPML filters are applied
);
// Run the query
$query = new WP_Query($args);
// Use the results as needed
if ($query->have_posts()) {
while ($query->have_posts()) {
$query->the_post();
// Your loop content
}
wp_reset_postdata();
}
If this solution does not resolve your issue or seems outdated, please check the related 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, we highly recommend opening a new support ticket at WPML support forum.
Problem: You are trying to get the sitemaps working for all languages on your website using the WPML SEO plugin and Yoast Premium. However, sitemaps are only working for the primary language and not for other languages. Solution: We recommend checking if you are using different language domains, as this functionality is primarily available in such setups. You can find more details on this in our documentation: Using WordPress SEO with WPML. Please note that sitemap generation is managed by Yoast, not by us. If you need separate sitemaps for each language and are not using different domains, you might need to implement a custom solution, as this falls outside the standard behavior.
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 our support forum.
Problem: The client is developing a site and needs a separate payment gateway for each currency. The gateway is custom coded, and the client wants to make it compatible with WPML's multicurrency feature. Solution: We recommend setting up your payment gateways in the Payments section of WooCommerce>>Settings, as these should be available for all currencies added via WooCommerce Multilingual Multi Currency features. For more details, please refer to our documentation on multi-currency support in WooCommerce.
Our developers have confirmed that normally any payment gateways configured should be available for all supported currencies. However, our documentation lists only the most common payment methods like WooCommerce PayPal Payments, Stripe, and direct bank transfers.
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 further assistance is needed, please open a new support ticket at WPML support forum.
Problem: The client wants to format the language switcher in their website header to display languages with a '/' between them, specifically as 'EN/GR'. Solution: If you're experiencing this, we recommend you follow these steps: 1. Enable the language switcher. 2. Configure it to show only language codes by following the instructions here: https://wpml.org/forums/topic/use-language-abbreviations-in-menu-language-switcher/ 3. Use custom CSS to add '/' between the languages. Here is an example of how you can do it:
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 this does not resolve your issue, please open a new support ticket at WPML support forum.
Problem: Wenn Sie einem neu hinzugefügten Admin-User oder einem User, der zuvor nur Redakteur war und nun Admin-Rechte erhalten hat, die vollen WPML-Zugriffs- und Bearbeitungsrechte geben möchten, aber feststellen, dass diese Rechte nicht automatisch zugewiesen werden. Solution: Eine mögliche Lösung ist die Installation eines Plugins zur Verwaltung von Nutzer-Berechtigungen, um dem Nutzer alle notwendigen Rechte hinzuzufügen. Ein empfohlenes kostenloses Plugin finden Sie hier: https://wordpress.org/plugins/user-role-editor/ Alternativ können Sie eine programmatische Lösung verwenden:
function add_wpml_capabilities_to_user($user_id) {
$user = get_user_by('ID', $user_id);
if ($user && $user->exists()) {
$wpml_capabilities = [
'wpml_manage_languages',
'wpml_manage_translation_options',
'wpml_manage_troubleshooting',
'wpml_manage_site_languages',
'wpml_manage_translations',
'wpml_manage_translation_management'
];
foreach ($wpml_capabilities as $capability) {
$user->add_cap($capability);
}
echo "WPML capabilities have been added to user ID $user_id.";
} else {
echo "User with ID $user_id does not exist.";
}
}
add_wpml_capabilities_to_user(123);
Ersetzen Sie '123' mit der tatsächlichen Benutzer-ID. Dieses Snippet sollte am Ende der functions.php Ihres Child Themes hinzugefügt und nach der Ausführung entfernt werden.
Falls diese Lösung veraltet ist oder nicht auf Ihr Problem zutrifft, empfehlen wir Ihnen, ein neues Support-Ticket zu öffnen. Überprüfen Sie auch die bekannten Probleme und stellen Sie sicher, dass Sie die neuesten Versionen Ihrer Themes und Plugins installiert haben.