WPML Multilingual CMS 5.2.0

Date de publication: 21 octobre 2026
Canal: Stable
Testé avec WordPress: 7.1
Produit: WPML Multilingual CMS

Journal des modifications

Des sauvegardes et des pages plus rapides, un Tableau de bord de traduction repensé, une traduction automatique plus claire et 355 correctifs.

Nouveautés

La traduction automatique ne laisse plus les travaux en cours lorsque le compte ne peut pas payer : elle se met en pause avec Accéder à la facturation et reprend une fois le paiement effectué.
La liste de contenu du Tableau de bord de traduction est reconstruite : elle fonctionne sur les sites avec de nombreuses langues, liste chaque article une fois, et ses filtres de statut correspondent à la colonne.
La modification de la préférence de traduction d’un champ personnalisé met à jour votre contenu existant sous forme de tâche en arrière-plan suivie, et les paramètres expliquent ce que fait chaque préférence.
Les petites modifications apportées au contenu traduit ne perdent plus les traductions existantes et ne sont plus facturées comme une nouvelle traduction complète.
Le nom et la description d’une catégorie ou d’une étiquette sont traduits et facturés une seule fois, et non à nouveau dans chaque article qui les utilise.
Les variations de produits restent exclues de Tout traduire, et les travaux de variation vides créés précédemment sont retirés.
L’annulation d’un travail pour un contenu qui était déjà traduit restaure son état précédent.
Les écrans de l’interface d’administration de WPML suivent votre langue d’administration, y compris les langues s’écrivant de droite à gauche.
Le nombre de commentaires est affiché par langue, et les statuts des articles restent synchronisés entre les originaux et leurs traductions.
Le mode de révision est conservé par lot de traduction, et l’Éditeur de traduction avancé marque les textes des médias et de la taxonomie dont l’original a changé.
Multisite : l’assistant de configuration du sous-site gère correctement la clé du site, sans requête d’utilisateurs défectueuse, et les sous-sites ne signalent plus d’incohérence de clé du site.
Priorité de traduction est supprimée, et Réinitialiser WPML est bloqué tant que le site a encore des langues secondaires.
L’enregistrement du site auprès de wpml.org inclut sa configuration et l’état de la traduction automatique ; une case à cocher facultative dans l’assistant de configuration et les Paramètres contrôle le partage des statistiques de votre contenu et de la liste des extensions.
Tous les modules complémentaires de WPML sont construits à partir de la même source que WPML et sont publiés en même temps que lui.
Chaque module complémentaire de WPML contient la même version de bibliothèque partagée que WPML, de sorte que la notification « WPML Update is Incomplete » reste traduite quelle que soit l’extension qui se charge en premier.
Renforcement de la sécurité : gestion plus stricte des données stockées, validation des entrées de requêtes, suppression plus sûre des fichiers, des noms de fichiers et des chemins d’inclusion, et échappement des valeurs stockées.
Lorsque le rôle Administrateur a perdu les capacités de WPML, WPML les restaure, afin que les nouveaux administrateurs voient l’intégralité de WPML.
L’avertissement relatif aux exigences minimales de l’assistant de configuration ne peut plus être ignoré puis perdu.
Lorsque l’envoi de contenu à la traduction échoue en raison d’un problème de base de données, la fenêtre contextuelle affiche les détails de l’erreur.
Lorsque WPML ne peut pas lire les mots disponibles de votre compte, il affiche un statut et un message clairs.
Un travail qui n’arrête pas d’échouer à côté de ceux créés avec succès n’est plus réessayé sans limite.
Lors d’une panne de connexion que seul un nouvel envoi peut résoudre, la bannière n’affiche plus de compte à rebours avant la nouvelle tentative.
Dans la File d’attente de traduction, les statuts cochés dans le filtre Statut restent cochés après le chargement de la liste des travaux.
La notification « Votre tarification de traduction automatique a été mise à niveau » sur le Tableau de bord de traduction affiche désormais son contenu au lieu de rester vide.
Le choix de « Copier à partir de la langue d’origine si la langue de traduction utilise des URL encodées » vous avertit lorsqu’aucune langue active n’utilise d’URL encodées.
Les sélecteurs de langue déroulants s’ouvrent désormais avec le clavier et par clic, et indiquent aux lecteurs d’écran s’ils sont ouverts.
L’icône de la liste déroulante du sélecteur de langue n’apparaît que lorsqu’il y a des traductions parmi lesquelles choisir.
Le sélecteur de langue est désactivé lorsque le site n’a qu’une seule langue active.
Le sélecteur de langue sur l’archive annuelle d’un type de publication personnalisé renvoie vers la bonne archive.
Les aperçus des articles et des pages utilisent la bonne adresse sur les sites avec un domaine différent par langue.
La liste des articles affiche la bonne icône pour une traduction en cours.
Le contenu avec des éléments temporels garde son code HTML intact lorsqu’il est divisé pour la traduction.
Travailler dans plusieurs onglets du navigateur ne mélange plus les langues dans l’éditeur de blocs.
Les informations sur la paire de langues mises en cache à partir de l’Éditeur de traduction avancé ne deviennent plus obsolètes et se réparent d’elles-mêmes.
La connexion d’une traduction à un autre groupe de traduction n’échoue plus tout en signalant un succès.
Les listes d’administration des types de publication hiérarchiques, comme les Pages, n’exécutent plus de requête de traduction sur chaque article, ce qui échouait sur les hébergeurs limitant la taille des requêtes.
La traduction automatique des catégories, des étiquettes et d’autres termes est plus fiable.
Les anciennes adresses d’administration des outils de Support mènent à l’unique page de Support au lieu de copies séparées.
Les blocs détectés automatiquement à partir de constructeurs basés sur des champs tels que Meta Box n’offrent que leurs attributs de texte pour la traduction.
Avada : le widget Fusion Post Cards est traduit.
WP User Manager : le sélecteur de langue sur une page de profil mène à la page de profil traduite, et non à la page générique.
Lorsque la reconnexion d’un site copié ou déplacé échoue, WPML n’efface plus sa clé du site, de sorte que les mises à jour et la traduction automatique continuent de fonctionner.
Un attribut de shortcode enregistré comme encodé en base64 qui contient en réalité du texte brut peut désormais être traduit.

Performances

L’enregistrement d’une page ou d’un modèle, y compris les modèles Elementor, ne réécrit plus les traductions inchangées, de sorte que les sauvegardes sur les sites avec de nombreuses langues sont beaucoup plus rapides.
Les pages de l’interface publique sur les sites WooCommerce se chargent plus rapidement : les règles d’URL ne sont plus relues pour chaque terme de produit.
Une requête de l’interface publique mise en cache n’interroge plus la base de données sur les tables de langue de WPML à chaque vue de page.
Les requêtes de l’interface publique n’écrivent plus la progression de la montée en gamme ni ne relisent la structure des tables de WPML.
Les écrans de modification des articles n’attendent plus la recherche du moteur de traduction à chaque chargement, et une recherche qui échoue n’est pas réessayée sur chaque page.
La modification d’un article sur un site avec de nombreuses extensions ne manque plus de mémoire.
Le tableau de bord de Gestion de traduction n’expire plus sur les sites avec de nombreux termes traduits.
Le tableau de bord de Gestion de traduction ne manque plus de mémoire lors du comptage des mots.
WPML > Traductions ne manque plus de mémoire sur les sites avec un cache d’objets persistant, tel que Redis ou celui de WP Engine.
La table de cache de résolution d’URL ne croît plus sans limite, et l’enregistrement des paramètres de routage ne compte plus la table entière.
Les requêtes de termes avec de longues listes d’inclusion, d’exclusion ou d’enfants, comme dans les menus, les widgets et les filtres de produits, sont traduites en une seule requête de base de données.
Les traductions des termes de produits lues en dehors d’une requête sont recherchées une fois par requête.
Les textes par défaut des blocs sont traduits lors du rendu d’un bloc, et non pour chaque type de bloc enregistré à chaque requête.
Les commandes WP-CLI utilisent moins de mémoire : WPML charge son programme d’installation uniquement lorsqu’une commande en a besoin.
Multisite : le basculement entre les sites n’exécute plus de vérifications de récupération lorsqu’il n’y a rien à récupérer, de sorte que les pages d’administration du réseau se chargent à nouveau rapidement.
Les traductions de produits sont recherchées en une seule requête pour les produits affichés par les blocs de collection de produits WooCommerce.
WP Rocket optimise la page racine du site comme chaque répertoire de langue, et n’enregistre plus « Empty buffer » pour celle-ci.
Les pages Elementor n’exécutent plus tous les convertisseurs d’ID dynamique WooCommerce sur chaque élément.
Les pages d’administration ne réenregistrent plus les textes par défaut de chaque bloc tiers à chaque requête, ce qui économise de nombreuses requêtes de base de données.
Sur certains sites ayant fait l’objet d’une montée en gamme, l’actualisation du catalogue de langues s’exécute une fois au lieu d’à chaque requête.
L’enregistrement d’un article ne revérifie plus les tables de WPML à chaque fois, et un article de blocs ne lit son paquet de chaînes qu’une seule fois.
Les pages de l’interface publique des thèmes basés sur des blocs et des boutiques WooCommerce lisent les traductions de blocs, les slugs de termes et les règles d’URL traduites une fois par page, et non à chaque utilisation.
Les valeurs que WPML met en cache sans expiration sont conservées au lieu d’être traitées comme expirées et supprimées.
La recherche de termes par slug ne répète plus le même ajustement pour chaque recherche dans une requête.
WPML n’effectue plus de trace de la pile complète à chaque recherche d’URL d’accueil, et son filtre d’URL d’accueil est mis en cache.
WPML ne charge plus son moteur de modèles d’e-mail sur chaque page d’administration, requête REST et appel AJAX, de sorte que moins de fichiers se chargent.
Les pages d’administration ne comptent plus les articles portant des champs personnalisés qui attendent votre décision à chaque chargement.
Les pages d’administration ne sont plus ralenties par une vérification lente de l’API REST et des erreurs de décompression de données.
Constructeurs de pages : l’enregistrement de plusieurs traductions en une seule requête ne reconstruit plus chaque article précédent à nouveau.
La liste des articles n’exécute plus de requête de traduction pour chaque ligne.
La page des paramètres de Traduction IA se charge sans attendre les réponses de notre système de traduction.
L’enregistrement des articles est plus rapide sur les grands sites multilingues.
L’application d’une traduction à un article avec de nombreux champs personnalisés est plus rapide.
La page de Traduction de la taxonomie n’expire plus sur les sites avec un très grand nombre de termes.
Le Tableau de bord de traduction lit les types de contenu traduisibles une fois par page au lieu de deux.

Correctifs pour la traduction automatique et Tout traduire

Tout traduire ne reste plus en pause pour le plafond de dépenses mensuel après que le plafond a été augmenté ou que le mois a été réinitialisé.
La boîte Tout traduire en pause affiche le plafond de dépenses mensuel actuel et l’utilisation de ce mois-ci.
Les textes qu’une traduction antérieure avait seulement copiés depuis la langue d’origine, comme les messages de formulaire non traduits, sont désormais traduits automatiquement au lieu d’être traités comme terminés, tandis qu’une copie qu’un traducteur a complétée volontairement est conservée.
Tout traduire applique les traductions de termes dont la description contient du code HTML, comme une image, et un travail de terme ayant échoué indique sa raison.
Les estimations de coûts de Tout traduire omettent les langues en pause, y compris les éléments dont la seule traduction manquante est dans une langue en pause.
Les traductions automatiques sont livrées même lorsqu’une traduction antérieure du contenu a été supprimée, et un travail ayant échoué n’affecte plus les autres.
Les sites auxquels WPML demande les traductions terminées continuent de les collecter jusqu’à ce qu’il n’en reste plus aucune, de sorte qu’un grand lot arrive en quelques minutes, et non en quelques jours.
Ignorer un travail de traduction automatique ayant échoué le supprime définitivement, et ses textes ne sont plus renvoyés à la traduction automatique.
Le passage des chaînes de Tout traduire ne ralentit plus sur les sites avec de nombreux lots passés.
Une traduction automatique ayant échoué d’un article, d’un lot de chaînes, d’un paquet de chaînes ou d’un terme, qui a été ignorée ou annulée, n’est pas renvoyée tant que son contenu ne change pas.
L’action « Synchroniser les ID de travaux locaux avec les travaux de l’ATE » refuse les mappages de travaux ambigus, de sorte qu’une livraison n’est jamais écrite dans une traduction non liée.
Le changement du moteur de traduction dans les paramètres de Traduction IA signale un enregistrement ayant échoué comme échoué, au lieu d’afficher Enregistré.
La boîte « n’a pas pu être terminé » ne liste plus un travail avec chaque détail à N/A après avoir cliqué sur Ignorer les travaux.
Les traductions livrées pendant qu’un écran d’article est ouvert conservent leur lien vers l’original et leur langue lorsqu’une autre extension gère les enregistrements d’articles.
Tout traduire ne saute plus un terme créé pendant qu’il termine cette taxonomie.
Les pages d’administration de WPML continuent de fonctionner lorsque l’Éditeur de traduction avancé donne une réponse inattendue concernant le mappage des langues.
Tout traduire enregistre chaque élément terminé une fois, et la suppression d’une langue l’efface également des enregistrements de Ninja Forms et de WPForms.
Les estimations de coûts de Tout traduire, y compris celles de l’assistant de configuration, comptent les articles avec leurs champs de termes, les chaînes, les paquets de chaînes et les étiquettes de taxonomie au fur et à mesure qu’ils sont envoyés.
L’estimation du coût de la traduction automatique liste ce qu’elle ne compte pas, de sorte que l’utilisation finale ne réserve aucune surprise.
Tout traduire ne reste plus bloqué sur les textes des widgets de blocs en dehors des écrans d’administration, et le contenu qu’il ne peut pas envoyer ne bloque plus les articles ultérieurs.
Tout traduire n’écrase plus la progression qu’une autre requête a enregistrée en même temps.
La note sous le tableau de nombre de mots de Tout traduire explique qu’après la première traduction, les modifications sont gratuites et que vous ne payez que pour les mots ajoutés.
Tout traduire envoie un paquet de chaînes de Widgets ajouté pendant que les Widgets étaient exclus, une fois que les Widgets sont à nouveau inclus.
Lorsque WPML ne peut pas joindre le site pour vérifier les traductions livrées, la boîte de statut indique que les vérifications se sont arrêtées et propose de les récupérer maintenant.
Lorsque notre système de traduction continue de refuser l’adresse du site, WPML indique qu’il se reconnecte et continue d’essayer, sans demander de mapper la langue par défaut.
Le fait d’appuyer sur Récupérer les traductions maintenant pendant une vérification de livraison collecte les traductions juste après la fin de cette vérification.
Lorsque plusieurs pages d’administration sont invitées à se reconnecter à notre système de traduction en même temps, WPML n’enregistre le site qu’une seule fois.
Une langue ajoutée avec « traduire le contenu existant » pendant que WPML se reconnecte voit son contenu existant traduit une fois la connexion rétablie.
Le bouton Traduire le contenu n’est plus désactivé sans explication pendant que WPML se reconnecte à notre système de traduction.
Les sites avec des traductions en cours vérifient celles qui sont terminées toutes les deux minutes comme prévu, et la vérification ne bloque plus votre navigateur.
Lors d’une reconnexion, l’Étape 2 du Tableau de bord de traduction n’affiche aucun compte à rebours de nouvelle tentative ni de message « impossible de joindre », et le bouton Tout traduire mis en attente explique pourquoi.
L’estimation de Tout traduire nomme la ligne des widgets de blocs « Bloc » au lieu de « Widget » ou « Widgets ».
L’estimation du coût de l’assistant de configuration ne compte plus la catégorie d’un article dans une langue dans laquelle elle est déjà traduite, ce qui correspond au Tableau de bord de traduction.
Un travail que le moteur de traduction n’a pas pu traduire apparaît dans la liste des travaux qui n’ont pas pu être terminés, avec Renvoyer et Ignorer.
Tout traduire n’envoie ni ne facture plus une étiquette de taxonomie deux fois lorsque son enregistrement de statut est perdu.
L’activation de Tout traduire ne prétend plus que la langue par défaut n’est pas prise en charge lorsque WPML n’a tout simplement pas pu lire les informations de support.
Pendant que WPML se reconnecte à notre système de traduction, la boîte Tout traduire reste visible dans un état en pause et explique ce qui se passe.
Une traduction qui n’arrête pas d’échouer à s’appliquer est abandonnée après la troisième tentative et listée avec Renvoyer et Ignorer ; Renvoyer démarre un nouveau travail.
WPML reconnaît les réponses « mappage de langue manquant » de notre système de traduction et efface l’icône d’erreur d’un travail annulé à cet endroit.
Au retour de l’Éditeur de traduction avancé, WPML indique quand la traduction n’a pas pu être enregistrée, avec la raison et l’étape suivante.
Les traductions automatiques continuent d’être livrées lorsqu’une autre extension ne parvient pas à enregistrer l’une d’elles, et la progression de la barre d’administration ne redémarre plus à zéro.
Après avoir payé via le widget de compte sur le tableau de bord WordPress, la boîte de traduction automatique en pause s’efface immédiatement.
Avec le Paiement à l’usage, les travaux bloqués par un paiement en attente ou ayant échoué indiquent pourquoi ils attendent et comment continuer.
Une panne de connexion avec notre système de traduction ne se termine que lorsque l’envoi fonctionne à nouveau, et Réessayer ne laisse plus passer un travail en double.
Après un envoi vers la traduction automatique, le résultat ne compte que les travaux réellement créés, et Réessayer ne remplace plus un travail retenu à chaque fois.
Lorsqu’une partie d’un envoi de Tout traduire échoue, les éléments ayant échoué sont conservés et renvoyés plus tard.
Une réponse que WPML ne peut pas lire, comme une page de proxy, ne bloque plus définitivement ces éléments de la traduction automatique.
Les envois depuis l’extérieur du Tableau de bord de traduction, comme l’éditeur d’articles ou la liste des articles, ne sont plus refusés pendant que WPML attend la fin d’une panne.
La notification de connexion distingue les problèmes de compte des problèmes de l’Éditeur de traduction avancé, de sorte que l’un ne cache plus l’autre.
Une nouvelle panne de connexion n’affiche plus « accès impossible » immédiatement parce qu’une autre requête a fermé la panne précédente en plein envoi.
Les envois de chaînes qui échouent, sont écourtés, ciblent une langue en pause ou sont refusés ne laissent plus de lots de chaînes vides derrière eux.
Le renvoi d’un travail de terme ayant échoué conserve le terme, et un renvoi ayant échoué est signalé comme échoué.
La désactivation de Tout traduire pendant que des chaînes sont en cours de traduction ne les laisse plus définitivement sur « Traduction en cours ».
Sur les écrans de la largeur d’un téléphone, la fenêtre Configurer Tout traduire s’adapte à l’écran et peut être fermée.
Tout traduire ne renvoie plus, et ne facture plus à nouveau, un travail que vous avez annulé alors que son premier passage sur l’ensemble du site est toujours en cours d’exécution.
Les travaux de taxonomie mis en pause parce que le compte n’a plus de mots reprennent une fois que des mots sont ajoutés.
Le tableau de bord ne compte plus les travaux que notre système de traduction n’a jamais acceptés comme étant en attente, de sorte qu’aucune traduction fantôme n’attend d’être récupérée.
Lorsque WPML ne peut pas lire quelles langues la traduction automatique prend en charge, les estimations de coûts et la liste des langues du Tableau de bord de traduction ne ressortent plus erronées ou vides.
Tout traduire ne liste plus un type de contenu n’ayant rien à traduire comme étant en attente de votre approbation.
Les types de contenu qu’une extension enregistre uniquement dans l’interface d’administration, comme le Grid Builder de WPBakery, peuvent être inclus à partir de Ajuster les limites de contenu.

Correctifs dans les éditeurs de traduction et les travaux de traduction

Les traductions existantes de l’Éditeur de traduction classique de contenu avec plusieurs blocs sont conservées lorsqu’elles sont ouvertes dans l’Éditeur de traduction avancé.
L’Éditeur de traduction classique affiche le code HTML avec des éléments vidéo, audio et image dans un champ de texte brut, de sorte qu’aucune balise n’est perdue.
Dans l’éditeur de traduction, un texte répété dans plusieurs blocs, shortcodes ou attributs est listé sous sa première occurrence, de sorte qu’aucun bloc ne semble manquer.
L’achèvement d’un travail de traduction n’écrit jamais dans, ni ne déplace, un article qui n’est pas la propre traduction du travail.
Dans l’Éditeur de traduction classique, un travail dont la source est une langue secondaire ne charge plus la page de la langue par défaut à la place.
L’ouverture d’un travail de traduction envoyé depuis une autre traduction, et non depuis l’original, conserve cette traduction comme langue source.
Un paquet de chaînes ou un article révisé dans l’Éditeur de traduction avancé se termine et se publie lorsque le relecteur clique sur Enregistrer et Terminer.
La réouverture d’une traduction de produit livrée ne crée plus un nouveau travail avec des champs vides ; l’éditeur attend que la traduction soit collectée.
Une cible vide dans un fichier XLIFF livré n’annule plus le travail : les unités sans texte conservent la source, et les mauvaises unités sont ignorées.
L’ouverture d’une traduction dans l’éditeur ne prend plus le dessus sur un travail automatique que notre système de traduction est encore en train de traduire.
L’acceptation d’une traduction révisée d’un article planifié ne le publie plus avant son original.
Dans l’éditeur de traduction, un texte de shortcode de constructeur de pages est libellé avec uniquement les attributs qu’il possède actuellement.
Dans l’éditeur de traduction, les shortcodes à l’intérieur des blocs sont listés dans l’ordre de la page, avec une entrée par texte répété.
Dans l’éditeur de traduction, une page avec des shortcodes à l’intérieur de blocs affiche ses deux groupes de textes sous des noms différents.
Aucun travail de traduction n’est créé pour une traduction dont l’enregistrement de statut a été supprimé par un enregistrement simultané, de sorte que les avertissements PHP associés ont disparu.
L’échec de l’écriture d’un enregistrement de statut de traduction ne renvoie plus l’ID d’une autre traduction.
Les enregistrements simultanés d’une traduction qui n’a pas de travail créent un travail de base, et non un chacun.
Une traduction de terme révisée dans l’Éditeur de traduction avancé est à nouveau appliquée au site.
Les fichiers d’une archive de travail de traduction téléchargée ont des noms que Windows accepte, de sorte que l’archive s’extrait partout.
Lorsque l’article traduit ne peut pas être créé ou mis à jour, le travail est signalé comme ayant échoué avec sa raison et peut être appliqué à nouveau.
L’Éditeur de traduction classique affiche correctement un shortcode entre guillemets doubles à l’intérieur d’un attribut entre guillemets doubles.
La réouverture d’une traduction à partir d’un lien avec son ID de travail conserve la progression non enregistrée du traducteur.
Après qu’un administrateur a ouvert une traduction terminée, la suppression du traducteur ou l’importation d’un fichier XLIFF laisse le travail dans le bon état.
Sur la page de révision de traduction, les liens du sélecteur de langue pointent vers leurs propres langues, et non vers la langue en cours de révision.

Correctifs dans la Gestion de traduction et le Tableau de bord de traduction

Les liens de modification des articles traduits restent en place pour les utilisateurs n’ayant pas de paire de langues de traducteur.
L’icône de crayon d’un article dupliqué ouvre à nouveau l’éditeur WordPress lorsque celui-ci est l’éditeur de traduction choisi.
Les articles traduits dans l’éditeur WordPress s’y ouvrent à nouveau tant que notre système de traduction ne reconnaît pas la nouvelle adresse du site, et les traductions bloquées indiquent pourquoi.
Les éditeurs peuvent ouvrir l’article original à partir de la colonne de statut de traduction sans erreur de type « non autorisé à traduire cette paire de langues ».
L’envoi d’une page, d’une catégorie ou d’une étiquette à nouveau depuis une autre langue, avant que sa traduction n’existe, affiche la nouvelle langue source dans les Travaux de traduction.
Lorsque l’enregistrement automatique des chaînes est désactivé, le retour à la fenêtre du Tableau de bord de traduction ne démarre plus le traitement des chaînes.
Une traduction qui ne peut pas s’ouvrir dans un éditeur explique pourquoi au-dessus de la liste des Tâches de traduction, comme le fait la liste des articles.
Annuler et Enregistrer dans la boîte de dialogue d’enregistrement automatique des chaînes ne quittent plus le Tableau de bord de traduction pour une page blanche.
La modification de la langue d’un original met à jour la langue source de ses traductions, de sorte que leurs travaux restent listés dans les Travaux de traduction.
La liste des travaux n’affiche plus d’erreur de base de données pour un traducteur dont la paire de langues n’a pas de langues cibles.
L’e-mail de mises à jour de traduction ne compte plus un travail de paquet de chaînes comme étant l’article avec le même ID.
Traduire le contenu reste disponible pour une sélection mixte lorsqu’un type d’élément est déjà traduit.
L’e-mail de résumé des travaux n’affiche plus d’avertissement PHP lorsque le gestionnaire d’un travail n’est pas un utilisateur.
Le Tableau de bord de traduction envoie les catégories marquées « Traduire automatiquement » même lorsque l’envoi précédent utilisait « Traduire moi-même ».

Correctifs pour les constructeurs de pages

Elementor : la modification d’une traduction ouvre l’éditeur dans votre langue d’administration, et non dans la langue de la page.
Elementor : l’enregistrement d’une traduction n’échoue plus lorsqu’un widget de thème a besoin du document actuel ou qu’un widget rencontre une erreur lors du rendu.
Elementor : chaque bouton sur une page traduite renvoie vers la traduction de sa propre cible, et non tous vers la même page.
Elementor Pro : le champ Message du widget Form n’est plus envoyé pour traduction, de sorte que les e-mails de notification conservent les données soumises.
Avada : les caractères accentués dans les e-mails de notification de formulaire traduits ne sont plus stockés sous forme de codes d’échappement.
WPBakery : une Single Image avec un lien personnalisé conserve son image et son lien sur la traduction.
Les valeurs de constructeur de pages qui ne sont pas des listes d’ID de pièces jointes ne sont plus réécrites en zéros sur les traductions.
Flatsome et autres constructeurs basés sur des shortcodes : le texte entre deux shortcodes du même nom est proposé pour la traduction et traduit.
Beaver Builder : sur une page traduite, le module Pattern et le panneau de compositions ne listent que les compositions de cette langue.
Divi 5 : un module Loop sur la page originale est conservé sur la traduction et liste les articles traduits.
Divi : les mises en page du constructeur de thème que Divi marque comme inutilisées ne sont plus proposées dans le Tableau de bord de traduction ni envoyées par Tout traduire.
Un shortcode ou un bloc déclaré dans plusieurs fichiers de configuration de langue conserve les attributs et les paramètres de tous ces fichiers.
Après un rechercher-remplacer, les constructeurs basés sur des shortcodes ne proposent plus le même texte deux fois, et les textes que la page ne possède plus sont supprimés.
Une page construite avec des shortcodes dont le contenu contient un commentaire de bloc voit sa traduction de l’Éditeur de traduction classique appliquée.
Un paramètre d’attribut ID de shortcode ne convertit plus également les autres attributs dont les noms se terminent de la même manière.
La traduction d’un attribut de shortcode ne modifie plus un autre attribut ayant le même texte.

Correctifs pour les blocs et l’éditeur de blocs

Sans la Traduction de chaînes, une page traduite conserve les paramètres d’un bloc inséré à partir d’une composition, et une nouvelle traduction répare les pages antérieures.
La modification du texte d’un widget de bloc conserve la traduction du texte qu’il remplace.
Les paramètres de bloc qui sont du code, tels qu’une balise HTML, un alignement ou un type d’animation, conservent leur valeur dans toutes les langues.
Les attributs de bloc contenant des listes d’ID, tels que les ID d’image de Galerie, affichent les éléments traduits.
Blocs HTML personnalisé : le code CSS contenant des images SVG n’est plus coupé, et le balisage échappé, les esperluettes et les espaces insécables restent tels qu’ils ont été écrits.
Les pages traduites ne transforment plus le texte qui affiche des balises HTML, écrit sous forme de texte dans un paragraphe, un titre ou une liste, en véritable balisage.
Les blocs traduits conservent leurs propres références : les copies de liens suivent l’ancre traduite, et les blocs d’images nomment la pièce jointe traduite.
Beaver Builder : un onglet ou un élément d’accordéon qui affiche une ligne, une colonne, un module ou un modèle enregistré affiche sa traduction.
Les blocs qui stockent un lien à la fois dans le balisage et dans les attributs, tels que les boutons GenerateBlocks, ne sont plus signalés comme rompus dans l’éditeur.
La configuration de langue propre à une extension ou à un thème est désormais appliquée dès son activation, de sorte que des blocs tels que Kadence Blocks peuvent être traduits immédiatement.
Les enregistrements de l’éditeur de blocs utilisent la langue de l’article, et non la langue d’administration, de sorte qu’un cours Sensei conserve ses modules.

Correctifs pour le sélecteur de langue

La navigation AJAX du sélecteur de langue ne lit que les réponses de pages HTML, en toute sécurité, de sorte que les autres réponses ne chargent jamais de ressources ni n’exécutent de code.
La fenêtre des paramètres du sélecteur de langue de pied de page ne s’ouvre plus vide, et les paramètres qui ne sont pas arrivés ne sont plus signalés comme enregistrés.
Les données du sélecteur de langue ne réinitialisent plus l’article actuel à l’intérieur des listes et des boucles.
Avec un domaine différent par langue et WP_HOME construit à partir de la requête, les liens du sélecteur de la langue par défaut utilisent son propre domaine.
Le bloc Sélecteur de langue fonctionne pour les utilisateurs n’ayant pas la capacité unfiltered_html : il s’enregistre proprement et conserve sa flèche, ses styles et la taille de l’image.
Un bloc Sélecteur de langue dont le balisage enregistré ne contient pas la langue actuelle ne provoque plus d’erreur fatale ; il liste les autres langues.
Dans l’éditeur de blocs, le bouton de bascule de la liste déroulante du Sélecteur de langue dirige les lecteurs d’écran vers sa liste de langues.
Deux blocs Sélecteur de langue sur une même page ne partagent plus un ID de sous-menu dans l’éditeur de blocs.
Les paramètres des sélecteurs de langue personnalisés affichent leurs propres règles de style, et un sélecteur ne peut plus être enregistré vide ou avec toutes les options d’affichage désactivées.
Les options du sélecteur de langue n’acceptent plus le code de modèle que chaque page afficherait ensuite.
Le bloc Sélecteur de langue affiche correctement les noms de langues accentués et non latins sur les hébergeurs disposant de versions plus récentes de libxml.
Le bloc Sélecteur de langue ne signale plus de contenu non valide pour les administrateurs dont la langue d’administration n’est pas l’anglais.

Correctifs pour les catégories, les étiquettes et les autres taxonomies

Une traduction de terme livrée sans l’un de ses textes, comme la description, reste ouverte pour la partie manquante au lieu de se terminer.
Une archive de taxonomie dont le slug est identique dans deux langues affiche le terme de la langue demandée, et ce terme s’enregistre à nouveau.
Le terme par défaut d’une taxonomie n’est plus réécrit à chaque changement de langue, et les nouveaux articles obtiennent le terme par défaut de leur propre langue.
Une extension vérifiant si un terme existe sur une page de langue secondaire récupère ce terme, et non sa traduction.
Le terme par défaut d’une taxonomie personnalisée ne peut plus être supprimé depuis l’interface d’administration d’une autre langue, ce qui faisait que WordPress le recréait dans la mauvaise langue.
Lorsqu’une catégorie ou un terme par défaut est supprimé par le code ou dans la base de données, WPML le recrée dans la langue par défaut avec ses traductions.
La modification du mode de traduction d’une taxonomie déplace chaque article sur le terme dans sa propre langue.
La suppression d’une catégorie ou d’un terme par le code depuis la page d’une autre langue classe ses articles sous le terme par défaut de leur propre langue, sans supprimer les autres termes par défaut.
Une langue ajoutée depuis une interface d’administration dans une autre langue obtient son propre nom de catégorie par défaut, tel que « Uncategorized » pour l’anglais.
Une traduction de terme créée via l’API de termes de WPML conserve la langue source nommée par son appelant.
La création d’une traduction de terme via l’API en nommant l’ID du terme original fonctionne et rejoint le groupe de traduction de l’original.
Le renvoi d’une catégorie ou d’une étiquette traduite ne renomme plus son slug lorsque l’original ou une autre langue le partage.
La langue d’administration ne bascule plus vers la langue précédemment parcourue après la visite de l’écran de Traduction de la taxonomie.
Les sites dont les ID de termes et les ID de taxonomie de termes diffèrent n’obtiennent plus de termes non liés dans les liens hreflang et les comptes de catégories.
Lorsque le terme par défaut anglais d’une taxonomie personnalisée a disparu et que ses traductions partagent son nom, chaque langue conserve son propre terme par défaut.
Une livraison tardive de traduction automatique n’écrase plus les traductions manuelles de termes ni n’efface leur état de mise à jour.

Correctifs pour les menus

Sur les sites avec un cache d’objets persistant tel que Redis, les menus traduits et les traductions de termes ne sont plus remplacés par ceux de la langue par défaut.
Dans les Menus, l’espace réservé « Traduction de » apparaît dans la langue d’administration, et non en espagnol.
L’enregistrement d’un menu en dehors de Apparence > Menus, via REST, l’Outil de personnalisation ou le code, le maintient lié à ses traductions.
Les éléments de menu ajoutés par le code en une seule requête conservent leurs positions.
La Synchronisation des menus WP crée des menus traduits à l’intérieur du groupe de traduction de leur original.
La Synchronisation des menus WP n’aplatit plus les menus traduits lorsqu’un fichier wpml-config, comme dans le thème Porto, définit les champs des éléments de menu à copier.
La suppression d’un élément du menu original supprime également ses copies traduites.
L’application des mêmes modifications de Synchronisation des menus WP à deux reprises ne crée plus un deuxième menu traduit.
La Synchronisation des menus WP n’ajoute plus de traductions en brouillon aux menus traduits, de sorte que les visiteurs n’obtiennent aucun lien 404.
La suppression d’un élément parent du menu original ne laisse plus les éléments enfants traduits pointer vers un élément supprimé.
La publication d’une modification de menu dans l’Outil de personnalisation avec une langue d’administration non par défaut ne renomme plus le menu traduit de cette langue.

Correctifs pour les liens, les URL et les redirections

La traduction ou la duplication d’un article dans plusieurs langues à la fois n’enregistre plus un lien vers un type de publication personnalisé avec un slug traduit dans la mauvaise langue.
Une page créée avec Créer la page racine est la page racine du site dès son premier enregistrement, dans les éditeurs de blocs et classique.
Une page en brouillon ou en attente avec le même slug ne renvoie plus une page publiée dans une autre langue vers une erreur 404.
Avec un domaine différent par langue, WPML > Paramètres > URL s’enregistre à nouveau au lieu d’échouer à une vérification pour un champ masqué.
Une adresse de catégorie se terminant par une catégorie qui n’existe pas, souvent demandée par les robots d’exploration, n’écrit plus d’erreur de base de données.
Les liens vers les archives et d’autres adresses qui ne sont pas des pages ne sont plus réécrits vers un modèle Elementor dans les traductions.
Les liens vers un article dont le slug est traduit sont convertis correctement dans la langue par défaut, quelle que soit la langue d’origine de l’article.
La page de connexion sur le domaine d’une langue masquée n’est plus redirigée vers la langue par défaut.
Avec une langue masquée et une page de connexion traduite, l’adresse de connexion de la langue masquée fonctionne toujours.
Lorsque WPML restaure un paramètre de format d’URL manquant lors du chargement d’une page, les liens de langue de cette page utilisent le format enregistré, et non les paramètres ?lang=.
Un site qui a perdu son Format d’URL de langue stocké continue de servir les répertoires de langues et enregistre à nouveau le paramètre.
Un champ de lien traduit contenant un lien simple vers la page traduite, tel que les Liens collants le stockent, ouvre cette page dans la langue de la traduction.
Une archive de catégorie ouverte par son adresse ?cat= et lang= affiche l’archive au lieu de rediriger vers la page d’accueil de la langue.
Les liens de page convertis, y compris les champs ACF Link et URL, conservent leur #ancre, leur chaîne de requête et leur sous-chemin.
Une adresse paginée ne fait plus pointer les liens vers le mauvais article.
Une nouvelle page racine obtient une langue après que l’ancienne page racine a été définitivement supprimée.
Le lien d’un terme se met à jour dès que le terme est enregistré, de sorte que les extensions SEO peuvent créer la redirection.
Les liens d’ancrage convertis n’obtiennent plus de barre oblique finale après l’#ancre.
Un lien ne reste plus dans la langue d’origine pendant un certain temps après la publication de sa traduction.
Les liens vers des articles non traduits ne mènent plus à une erreur 404 sur les sites avec un domaine différent par langue.

Correctifs pour les langues et l’assistant de configuration

L’assistant de configuration reprend à l’étape des langues lorsqu’il ne reste que la langue par défaut, au lieu de verrouiller l’interface d’administration.
L’étape Langues de l’assistant de configuration n’affiche plus de langue par défaut vide lorsque la langue par défaut enregistrée n’était pas active.
Dans l’assistant de configuration, l’ajout d’une variante nationale d’une langue que le site utilisait auparavant demande s’il faut conserver le contenu ou repartir de zéro.
Une langue qui n’est plus dans le catalogue de WPML peut être ajoutée en tant que langue personnalisée avec son propre code et ses propres paramètres régionaux.
La synchronisation du catalogue de langues remplit la langue d’un préréglage lorsqu’une version antérieure l’avait laissée vide.
Une direction de texte corrigée dans le catalogue de langues de WPML atteint les sites utilisant cette langue sans modifier leurs paramètres de langue.
Un code de langue « 0 » ne renvoie plus les liens vers la langue par défaut ; les sites affectés sont réparés, et les modifications de code ayant échoué sont signalées.
Une langue personnalisée créée avant WPML 5.0 sous un code que WPML utilise désormais, tel que de-at, devient cette langue intégrée, en conservant son contenu.
Une langue personnalisée qui ne peut pas être reprise est marquée Nécessite un mappage et n’est pas envoyée à la traduction automatique tant qu’elle n’est pas mappée.
La recherche de langue ne propose plus d’ajouter le chinois (Hong Kong) en tant que langue personnalisée une fois que le site l’a déjà.
Les téléchargements de packs de langues se terminent sur les hébergeurs avec une faible limite de temps PHP, reprenant au lieu de se bloquer au dernier pack.
La réinitialisation des valeurs par défaut de la langue n’affiche plus d’avis de dépréciation PHP 8.1.

Correctifs pour l’enregistrement et les mises à jour

La mise à jour de WPML par téléversement à partir de la version 5.1 n’affiche plus d’erreur critique unique.
La mise à jour de WPML n’envoie plus d’e-mail d’erreur critique lorsqu’une extension de gestion telle qu’InfiniteWP ajoute un article juste après la mise à jour.
Activer & Mettre à jour s’ouvre pour les comptes dont le type d’abonnement ne correspond à aucun produit, au lieu de s’arrêter avec une erreur critique.
Activer & Mettre à jour affiche la boîte d’enregistrement dans tous les états du compte, avec Désenregistrer et un champ de clé du site, de sorte que les anciens enregistrements puissent être remplacés.
Les détails d’extension des extensions WPML ne mettent plus en garde contre une version WordPress non testée sur les versions mineures de WordPress.
Un site enregistré n’affiche plus « A New Site Key Is Required » avec un cache d’objets persistant, et ne perd plus sa clé lorsque wpml.org est inaccessible.
Après qu’un site a déménagé vers une nouvelle adresse et conservé son compte de traduction, WPML indique que le site a déménagé au lieu de l’appeler une copie.
Multisite : Obtenir une clé pour ce site nomme l’adresse du réseau, de sorte que la clé vers laquelle il mène est acceptée.
Un site qui n’a pas déménagé n’affiche plus la notification de copie de site après s’être réenregistré auprès de notre système de traduction.
Lorsque le flux de produits WPML ne peut pas être joint, Activer & Mettre à jour conserve les derniers produits connus et indique ce qui a échoué, avec Vérifier à nouveau.
WP-CLI liste les extensions sans avertissement pendant qu’une mise à jour de WPML est en attente.
Après être revenu au canal Production, Activer & Mettre à jour installe la version de Production, et un Téléchargement sans rien à installer l’indique.
Les notes de version de chaque extension dans Activer & Mettre à jour n’affichent que les propres notes de cette extension.
Après la mise à jour, les navigateurs et les CDN chargent les scripts et les styles actuels de WPML au lieu des anciens mis en cache.
Advanced Custom Fields Multilingual et d’autres extensions complémentaires se chargent lorsque leur version est une version bêta de la version requise par WPML.
Un site ne revalide plus sa clé plusieurs fois par seconde, y compris lorsque plusieurs notifications de mise à jour arrivent en même temps.
Une clé du site définie dans wp-config.php conserve son enregistrement lorsque wpml.org ne fait que limiter le débit ou expire.
Le gestionnaire de téléchargement d’extension vérifie le jeton de sécurité de la requête avant de valider la clé du site.
Multisite : deux sites d’un même réseau avec des clés du site prédéfinies différentes ne se réenregistrent plus sans cesse.
L’assistant de configuration ne réenregistre plus une clé du site définie dans wp-config.php à chaque chargement.
La route de mise à jour de l’abonnement répond par un succès pour un site dont l’abonnement est déjà à jour, de sorte que les proxys et les moniteurs cessent d’enregistrer de faux refus.
Une clé du site dans wp-config.php est stockée correctement même lorsqu’elle est copiée avec un espace final ou un saut de ligne.
Les sites avec une licence Blog n’obtiennent plus d’erreur fatale concernant une constante manquante.

Correctifs pour les sites WooCommerce

Sur les sites avec WooCommerce Multilingual, WPML ne revient plus de lui-même à son assistant de configuration et affiche les articles de chaque langue.
Les scripts d’administration de WPML, CMS Navigation et Liens collants n’échouent plus avec « addLoadEvent is not defined » sur l’assistant de configuration de WooCommerce Multilingual.
La suppression d’une catégorie d’un produit met à jour le nombre de produits de la catégorie traduite dans chaque langue.
Les produits traduits avec l’Éditeur de traduction classique conservent les traductions de variations, d’attributs et de champs personnalisés lorsqu’ils sont ouverts dans l’Éditeur de traduction avancé.
L’importation de produits variables traduits n’échoue plus sur des lignes d’attributs en double lorsqu’un produit parent porte les termes des deux langues.
WooCommerce Multilingual ne reconstruit plus ses adresses de compte et de validation de commande traduites deux fois lorsque les types de contenu sont enregistrés tardivement.

Correctifs pour les champs personnalisés et Advanced Custom Fields

Les écrans de paramètres Traduction des champs personnalisés et Traduction des métadonnées de termes personnalisés s’ouvrent à nouveau lorsqu’une extension ou une importation a laissé une ligne de champ personnalisé sans nom.
Une tâche en arrière-plan mise en file d’attente sans demander après la mise à jour 5.1.0 est retirée ; un champ personnalisé nouvellement traduisible attend votre décision à la place.
Les paramètres de Traduction des métadonnées de termes personnalisés indiquent qu’un champ traduit est traduit avec le terme, et non avec l’article.
Les champs ACF imbriqués (Contenu flexible, Répéteur, Groupe) sur les termes de taxonomie sont traduits, automatiquement et dans l’éditeur.
Les sous-champs de répéteur et de contenu flexible définis sur Copier atteignent désormais les traductions lorsqu’une ligne est ajoutée en dehors de l’éditeur d’articles, par exemple avec update_field() ou un formulaire ACF sur l’interface publique.
Un champ personnalisé nouvellement traduisible marque comme « Nécessite une mise à jour » uniquement les articles traduits qui possèdent réellement le champ.
La modification de la préférence de traduction d’un champ ACF met également à jour les traductions de termes existantes.
Les étiquettes de groupes de champs ACF conservent leurs traductions après la migration vers Advanced Custom Fields Multilingual 2.2.
La montée en gamme depuis WPML 4.x ne restaure plus les anciens paramètres de champs personnalisés après le nettoyage d’Advanced Custom Fields Multilingual, ce qui gardait des données inutiles en chargement.
Dans la Traduction des champs personnalisés, une préférence choisie pendant le chargement des résultats de recherche est conservée, au lieu d’être perdue après « Données enregistrées ».
L’enregistrement d’une traduction via l’API REST à partir d’un client externe n’exécute plus une synchronisation complète des champs personnalisés à chaque fois.
Les champs personnalisés écrits après que WPML a copié les champs d’un article atteignent toujours ses traductions.
La modification d’un mot dans un champ ACF Link sur l’écran de Traduction de la taxonomie conserve le lien traduit.
La modification d’un champ ACF en Copier, Copier une fois ou Ne pas traduire dans les Paramètres de WPML met à jour les traductions existantes.

Correctifs pour les médias et les images

Traduction des médias : une page traduite dans l’éditeur de blocs conserve sa propre image après l’enregistrement de la traduction sur un hébergement avec cache d’objets.
L’achèvement d’un travail de traduction qui contient des médias ne crée plus de copies de pièces jointes orphelines dans chaque langue secondaire.
Une requête pour une pièce jointe dans une langue secondaire renvoie sa traduction, ou la pièce jointe elle-même, ce qui corrige les arrière-plans d’Enfold Color Section.
Une image qu’un constructeur de pages nomme par son URL affiche les textes de médias de la langue de la page.
Les images de constructeurs de pages, telles qu’un arrière-plan de section Divi, affichent les bons textes originaux dans l’éditeur de traduction et s’enregistrent sur la bonne image.
Une image sans adresse utilisable dans un widget ou un contenu ne provoque plus d’erreur de cache d’objets à chaque chargement de page.

Correctifs pour les articles et les pages

Les articles de types de publication personnalisés ne disparaissent plus des listes d’administration après qu’un fichier wpml-config.xml a rendu le type traduisible ; les sites affectés sont réparés lors de la mise à jour.
La suppression, la mise à la corbeille ou la restauration d’un article traduit à partir d’une tâche planifiée ou d’un formulaire de l’interface publique s’applique à ses traductions, comme dans l’interface d’administration.
L’enregistrement d’un article dont la ligne de base de données a disparu ne s’arrête plus sur une erreur fatale.
La restauration d’un article depuis la Corbeille conserve le statut de ses traductions ; les traductions en brouillon et privées ne reviennent plus publiées.
Un article planifié ne publie plus ses traductions mises à la corbeille ou inachevées à sa date lorsque les dates de publication sont copiées vers les traductions.
Les requêtes de l’interface publique ne plantent plus avec une récursion infinie lors de la résolution de la langue actuelle.
La mise à jour d’un article dont la langue est désactivée conserve cette langue, et l’enregistrement d’un article ne déconnecte plus une autre de ses traductions.
La vérification d’un ID d’article qui ne correspond à aucun article ne produit plus d’avertissements PHP.

Correctifs pour la compatibilité avec d’autres extensions et thèmes

Les pages d’administration d’autres extensions, telles que les options de Slider Revolution et d’Avada, chargent à nouveau leurs scripts avec WPML activé.
Aucune erreur critique sur chaque page lorsqu’une autre extension, telle que le constructeur Tatsu, recherche des articles pendant le chargement des extensions.
Lorsqu’une autre extension échoue pendant le chargement de WordPress, le site affiche à nouveau la page d’erreur critique de WordPress, et non une page blanche.
WPML restaure la langue du site lorsqu’une autre extension, telle que WP All Export Pro, la modifie et ne la rétablit jamais.
Les extensions de cache qui vident le cache d’objets ne provoquent plus d’erreurs de base de données « Commands out of sync », car WPML lit ses paramètres de page une seule fois.
Les sitemaps XML de Yoast SEO listent chaque article traduit sous sa propre URL lorsque WPML SEO n’est pas activé.
WPML SEO traduit les valeurs de texte de chaque type de schéma Rank Math.
The Events Calendar : la page racine n’apparaît plus blanche lorsque « Integrate events in main blog loop » est activé.

Correctifs pour les écrans d’administration et les paramètres

Un site dont le paramètre WPML stocké a été supprimé, par une extension de nettoyage ou une restauration partielle, le récupère à partir de la copie sauvegardée de WPML.
Les paramètres enregistrés pendant que WPML finalise la mise à jour de sa base de données ne sont plus perdus.
Dépannage : la reconstruction du cache pour une seule URL s’exécute de manière fiable en arrière-plan, et le clic sur Reconstruire n’est plus perdu.
La notification « Votre tarification de traduction automatique a été mise à niveau » ne s’affiche que pour les utilisateurs pouvant gérer les traductions.
Recherche dans les paramètres : l’entrée Localisation des thèmes et des extensions fait défiler jusqu’aux options de localisation sous Compatibilité.
L’ancienne adresse de Localisation des thèmes et des extensions mène à Paramètres > Compatibilité avec l’analyse des thèmes et des extensions affichée.
Les requêtes qui s’exécutent pendant l’action Réinitialiser WPML ne peuvent plus recréer les tables et les paramètres de WPML.
Réinitialiser WPML depuis l’administration du réseau vérifie également d’abord la présence de langues secondaires.
La suppression de Priorité de traduction n’écrit plus de faux enregistrement « élément supprimé » sur les sites faisant l’objet d’une montée en gamme.
La notification affichée lorsque la vérification de l’état de l’administration de WPML échoue nomme la requête qui a échoué.
Support > Journal de communication reste lisible après Actualiser les services.
Le changement du moteur de traduction est signalé lors de l’enregistrement quotidien du site auprès de wpml.org.
L’infobulle « Same as default » dans les paramètres de langue de WPML peut désormais être traduite.
Dans les requêtes REST d’administration, le changement des paramètres régionaux s’applique aux traductions comme prévu.

Correctifs pour les bases de données et le multisite

Sur les clusters de bases de données qui refusent les verrous nommés, tels que le mode strict de Percona XtraDB, WPML passe à un verrou basé sur les tables et continue de fonctionner.
WPML crée ses tables avec un jeu de caractères et un interclassement correspondants sur MariaDB 11.
WPML crée toutes ses tables avec un seul jeu de caractères et un seul interclassement, et une notification nomme toute table que la base de données refuse de créer.
Sur les bases de données qui refusent les verrous nommés, le journal du programme d’installation est écrit sans erreur de base de données.
Multisite : les sites du réseau où WPML est inactif, ou actif mais non configuré, n’enregistrent plus d’erreurs concernant une table de langues manquante.

Autres correctifs

La Traduction de chaînes n’écrit plus le fichier de traduction d’une langue à partir d’une langue inactive partageant ses paramètres régionaux, ce qui laissait des chaînes non traduites.
Traduction de chaînes : une chaîne supprimée qui provenait du texte par défaut d’un bloc, comme dans les blocs WooCommerce, ne revient plus.
L’importation d’un fichier .po dont les traductions contiennent des liens internes n’échoue plus avec une erreur de serveur.
La Traduction de chaînes enregistre et importe les fichiers de traduction des thèmes et des extensions lorsque WordPress est installé à la racine du système de fichiers du serveur.

Lisez l’annonce de la version publiée pour WPML 5.2 pour tout savoir sur cette version.

Mettre à jour ou télécharger

La mise à jour est disponible pour tous les clients WPML disposant d’un abonnement actif — elle apparaît sur la page Extensions de votre interface d'administration WordPress dans les 24 heures suivant sa publication. Vous pouvez également la rechercher immédiatement sous Extensions → Ajouter → Commercial. Pour la télécharger et l’installer manuellement, accédez à Téléchargements dans votre compte wpml.org (voir les instructions d’installation) et n’oubliez pas de mettre à jour tous les composants ensemble sans mélanger les versions.

Besoin d’aide ou envie de donner votre avis ? Veuillez utiliser notre forum d’assistance technique (s'ouvre dans un nouvel onglet).

Voir toutes les versions de WPML Multilingual CMS