Il s'agit du forum d'assistance technique de WPML, le plug-in multilingue pour WordPress.
Il est accessible à tous, toutefois seuls les clients de WPML peuvent y publier leurs messages. L'équipe du WPML répond sur le forum 6 jours par semaine, 22 heures par jour.
Sun
Mon
Tue
Wed
Thu
Fri
Sat
-
6:00 – 12:00
8:00 – 12:00
6:00 – 12:00
8:00 – 12:00
6:00 – 12:00
-
-
13:00 – 15:00
13:00 – 17:00
13:00 – 15:00
13:00 – 17:00
13:00 – 15:00
-
Fuseau horaire du support : America/Lima (GMT-05:00)
Enfin, j'ai voulu appliquer également les recommandations à un autre site en cours de développement mais même en créant une page incluant tous les blocs personnalisés Carbon Fields aucun champ personnalisé n'apparait dans les paramètres.
Dans la section "Traduction de champs personnalisés" j'ai le message "Aucun champ personnalisé n'a été trouvé. Il est possible que les champs s'affichent ici seulement après que vous ajoutiez d'autres publications et une fois que l'installation d'un nouveau plugin a été effectuée.".
Même en affichant les champs système et en cherchant le nom des champs utilisés pour les blocs, aucun n'apparait dans le tableau.
Les langues: Anglais (English )Français (Français )Arabe (العربية )
Fuseau horaire: Pacific/Easter (GMT-06:00)
Bonjour,
Le mélange d'éditeurs de traduction est une cause connue de ce comportement, mais je pensais que nous traduisions notre contenu uniquement avec WordPress et non avec l'éditeur WPML, n'est-ce pas ?
Si vous créez une traduction avec un éditeur, vous ne devez utiliser que cet éditeur, sinon, le mélange d'éditeurs peut causer des problèmes comme celui-ci,
Vous pourriez vérifier si la traduction automatique est activée, dans ce cas désactivez-la depuis WPML > Gestion de la traduction
Pour les champs personnalisés (carbon fields), essayez de cliquer sur "show system fields" sous WPML > Settings > Custom fields translation
Je n'ai pas pu vérifier cela sur le bac à sable que j'ai partagé car il affiche une erreur maintenant, voici un autre bac à sable dans ce cas : lien caché
Je vous confirme que la traduction automatique n'est jamais activée et que l'éditeur principal est configuré sur celui de WordPress au niveau global avant de le laisser aux rédacteurs.
Néanmoins je me demande s'il se pourrait qu'il y ait un bogue dans ce paramètre créerait une édition également via l'éditeur de WPML sans y passer lorsqu'il y a une actualisation des traductions ?
Je viens de vérifier et la traduction automatique est bien désactivée sur le site présenté initialement.
Pour ce qui est des champs personnalisés, ceux de Carbon Fields n'apparaissent pas non plus même en cochant la case "show system fields".
Même en ajoutant plein de blocs personnalisés.
Enfin, concernant le bac à sable, le premier semble toujours fonctionner de mon côté. Il n'y a pas de rendu de la part du thème. Les sites fonctionnent en headless sur la production.
Les langues: Anglais (English )Français (Français )Arabe (العربية )
Fuseau horaire: Pacific/Easter (GMT-06:00)
Bonjour,
Il est peu probable que les traductions reviennent en arrière ou soient supprimées sans un mélange d'éditeurs ou un autre plugin conflictuel (lié au cache, à la sécurité ou au CDN)
Mais juste pour être sûr, l'étape suivante serait de surveiller la table wp_icl_translate_job dans votre base de données,
C'est la table où tous les travaux de traduction sont sauvegardés et elle spécifiera quel éditeur a été utilisé pour chaque traduction ET si la traduction automatique a été utilisée.
On peut donc peut-être le surveiller et attendre que le problème se réplique à nouveau, vous pourrez alors confirmer si l'ATE ou la traduction automatique était en jeu.
Par ailleurs, je me suis souvenu d'un autre cas : lorsque vous traduisez les pages, ouvrez-vous toutes les langues en même temps dans des onglets différents ? ou bien une langue à la fois ?
Si oui, j'ai déjà eu un cas unique avec un comportement similaire où la traduction ne s'enregistre pas lorsque plusieurs onglets sont ouverts pour la même page dans différentes langues (« URL mismatch »), ce cas avait des paramètres d'URL très uniques, mais cela mérite d'être essayé si cela s'applique à vous.
Je viens de regarder la table `wp_icl_translate_job`.
Il se trouve que j'ai quelques entrée qui ne sont pas avec un éditeur du type "wp" mais "ate" ou "wpml" suivant les sites. Je vous joins une capture d'écran du site dont on parle.
Seulement, les posts référencé dans cette table pour avoir été traduit avec autre chose que l'éditeur Gutenberg n'ont pas été problématique. Les titres ne correspondent pas.
J'ai peur qu'on soit donc sur une fausse piste.
Est-ce qu'il y a moyen de pouvoir comparer les post_id pour en être sûr ?
Concernant les onglets j'ai demandé aux traducteurs. J'attends leur réponse.
Concernant la traduction des pages, les éditeurs font attention à n’ouvrir qu’un seul onglet à la fois, et à ne changer de langue que via les pages qui listent tous les posts, cependant le problème a persisté.
Étonnamment sur 3 sites, deux d'entre eux ont bien rencontré le problème mais pas le plus récent. Ils sont pourtant sur le même hébergement, base de donnée et la même configuration.
Est-ce que vous avez un outil qui vous permettrait de les comparer ?
Les langues: Anglais (English )Français (Français )Arabe (العربية )
Fuseau horaire: Pacific/Easter (GMT-06:00)
Bonjour,
Oui, vous pouvez comparer les ID et vérifier à quel post il se réfère en vous référant à ce diagramme de base de données : lien caché
Vous obtenez le job_id à partir de wp_icl_translate_job, puis vous recherchez cet ID dans wp_icl_translation_status, dans la deuxième colonne, vous devriez trouver le translation_id, recherchez cet ID de traduction dans wp_icl_translations.
Vous saurez alors quel post/attachement/contenu a été affecté par l'ATE.
Un autre conseil, si vous n'utilisez pas du tout l'ATE (advanced translation editor) sur votre site, désactivez-le dans WPML > Settings > Change editor to CTE (qui n'utilise pas la traduction automatique, et ne se connecte pas à distance à nos serveurs) juste pour l'éliminer de l'image.
Il y a quelque chose qui ne va pas dans le flux de travail, et je ne vois pas comment le suivre, sauf peut-être s'ils pouvaient enregistrer le problème d'une manière ou d'une autre (video par ex), je pourrais alors voir si quelque chose d'évident peut être remarqué.
Malheureusement, nous ne disposons pas d'un outil permettant de comparer les sites,
Je vous remercie pour votre retour. Après analyse de toutes les bases de données de différents site, je ne vois aucun lien entre les jobs de traduction et les pages posant problème.
Je vous joins des captures d'écran du résultat de la requête suivante :
```
SELECT
tj.editor,
tj.job_id AS job_id,
ts.translation_id,
t.element_type
FROM
wp_icl_translate_job tj
LEFT JOIN
wp_icl_translation_status ts ON tj.rid = ts.rid
LEFT JOIN
wp_icl_translations t ON ts.translation_id = t.element_id
WHERE
tj.editor NOT LIKE 'WP';
```
J'ai bien modifié le type d'éditeur WPML pour le "classique" sur tous les sites internet sans être certain que cela solutionne le problème.
Seul un site semblait avoir été configuré de cette manière et a tout de même rencontré le problème.
J'ai renouvelé ma demande auprès des éditeurs pour avoir un enregistrement vidéo.
Les langues: Anglais (English )Français (Français )
Fuseau horaire: America/Lima (GMT-05:00)
Bonjour,
Ilyes étant absent cete semaine, je réponds juste pour que le ticket reste ouvert et en attente de votre feedback. De cette manière, il retournera dans la liste de tickets d'Ilyes lorsque vous répondrez.
Le sujet « [Fermé] Écrasement des traductions » est fermé aux nouvelles réponses.
