Support de la traduction pour les constructeurs de pages à venir dans WPML

Il y a deux jours, nous avons mené une enquête pour vous demander comment vous aimeriez traduire les Sites conçus avec des constructeurs de pages. Dans cet article, j'aimerais partager les résultats et la façon dont cela influencera notre prochain développement sur WPML 3.6.

Contexte – Comment nous recommandons de traduire les Sites avec des constructeurs de pages aujourd'hui

Pour tous les constructeurs de pages, à l'exception de Toolset Layouts, la seule façon de traduire aujourd'hui est de créer des conceptions distinctes par langue.

C'est utilisable, mais pas très pratique. Nous pensons qu'il serait plus facile de concevoir une seule fois pour toutes les langues, et de ne traduire que les textes avec WPML. D'ailleurs, nous terminons la documentation sur la façon de tout traduire dans Toolset, y compris les mises en page. J'écrirai à ce sujet quand elle sera prête.

Q : Êtes-vous satisfait de la méthode actuelle de traduction du contenu créé avec des constructeurs de pages ?

Certaines personnes préfèrent en fait concevoir séparément par langue. C'est logique lorsque la conception entière doit être ajustée. J'imagine que si vous avez une conception très précise pour la page d'accueil du Site, il est logique de l'ajuster et de l'optimiser par langue.

La plupart sont OK avec ce que nous avons actuellement, mais préfèrent avoir une seule conception et traduire avec WPML. Et certains disent que cette approche n'est pas utilisable pour eux. Je pense qu'il s'agit de personnes qui utilisent des services de traduction. Je suis d'accord qu'il est presque impossible de demander à des traducteurs externes de toucher aux conceptions de votre constructeur de pages. Nous avons rencontré ces problèmes lors de l'intégration de WPML avec un certain nombre de services de traduction.

Q : Quels constructeurs de pages utilisez-vous souvent ?

Près de 60 % des Sites qui utilisent des constructeurs de pages utilisent Visual Composer. Les constructeurs très populaires suivants sont Divi et Avada. D'autres sont également assez populaires.

Comment se déroulera le processus de traduction ?

Comme nous avons déjà entièrement intégré cela et que cela fonctionne avec l'extension Layouts (bien que la documentation soit encore « en cours »), j'utiliserai Layouts comme exemple.

Étape 1) Concevez dans le constructeur de pages

Comme je l'ai expliqué, vous n'aurez besoin de concevoir qu'une seule fois dans le constructeur de pages. La même conception sera utilisée pour toutes les traductions.

Étape 2) Envoyez à la traduction

Lorsqu'une page utilise un constructeur de pages, vous devrez la traduire « deux fois ». Une première fois la page, ce qui inclura le titre de la page et tous les champs personnalisés que vous utilisez. Une deuxième fois la conception du constructeur de pages. Je sais que c'est un peu contraignant. Nous allons travailler pour automatiser cela, mais probablement pas dans un premier temps.

Accédez à WPML->Gestion de traduction. Vous y verrez de nouveaux Types de contenu pour les conceptions du constructeur de pages. Sélectionnez les conceptions que vous souhaitez traduire et envoyez-les à la traduction. Vous pouvez parcourir les différents éléments de votre Site et les ajouter au Panier de traduction. Lorsque vous avez terminé vos sélections pour la traduction, accédez à WPML->Gestion de traduction->Panier de traduction et envoyez tout ensemble en un seul lot. Vous pouvez traduire localement (avec l'Éditeur de traduction de WPML) ou en externe vers votre service de traduction préféré.

Étape 3) Traduisez

Vous verrez tous les textes qui appartiennent à la conception, côte à côte. Vous ne traduisez que les textes et non la structure. Traduisez et marquez chaque champ comme « Terminé ». Lorsque vous enregistrez, les traductions sont automatiquement appliquées à la conception du constructeur de pages.

Étape 4) Affichez les résultats sur l'interface publique

Vos traductions apparaîtront sur l'interface publique, lorsque vous afficherez le contenu. Vous ne verrez aucune traduction dans le constructeur de pages, car les traductions ne le modifient pas.

Étape 5) Mettez à jour la traduction lors de la mise à jour de la conception

Si vous modifiez la conception dans le constructeur de pages, accédez au Tableau de bord de traduction et renvoyez-la à la traduction. Seuls les textes modifiés apparaîtront pour la traduction.

Feuille de route pour l'intégration de la traduction pour les constructeurs de pages avec WPML

Nous commençons l'intégration avec Visual Composer, qui est malheureusement le moins pratique à intégrer. VC stocke la conception sous forme de shortcodes dans « le contenu ». Les shortcodes n'ont pas d'ID, il est donc difficile d'associer un élément à ses textes. Nous allons essayer de travailler avec les auteurs de VC pour ajouter des ID aux cellules. Quoi qu'il en soit, nous utiliserons une méthode de secours qui identifie les chaînes de texte en fonction de leur contenu. Cela signifie que si un texte change, vous devez le traduire à partir de zéro, car nous n'avons aucun moyen de savoir quel était ce texte avant que vous ne modifiiez la cellule. Nous ferons de notre mieux pour ajouter des ID aux cellules VC. J'espère que vous comprenez que cela ne dépend pas entièrement de nous.

Les autres constructeurs de pages fonctionnent différemment. Ils stockent la conception du constructeur séparément du « contenu » et les cellules ont des identifiants uniques. Ainsi, lorsque vous modifiez une cellule, vous verrez la traduction précédente et pourrez simplement la mettre à jour.

WPML 3.6 inclura certainement le Support de Visual Composer. Nous essaierons également d'inclure le Support de Divi. Dans le cadre du cycle de cette version publiée, nous rédigerons également une documentation détaillée sur la façon d'enregistrer des chaînes de texte pour la traduction dans les constructeurs de pages. C'est assez simple, cela nécessite juste d'être documenté correctement.

Ensuite, nous travaillerons avec tous les autres développeurs de constructeurs de pages pour intégrer ce Support dans leurs produits.

Des commentaires ?

Qu'en pensez-vous ? Je suis sûr que certains d'entre vous voudront que nous travaillions d'abord sur d'autres constructeurs de pages. Nous devons établir des priorités, nous commençons donc par ce que la plupart des gens utilisent. Nous ferons en sorte d'atteindre TOUS les constructeurs de pages à terme, et le plus tôt sera le mieux. J'aimerais avoir vos commentaires sur le processus de traduction et le plan global. Si vous avez des idées, des questions ou des suggestions, laissez vos commentaires et je vous répondrai.